[concurrency-interest] Concurrency Architecture

Norman Elton normelton at gmail.com
Sun Jun 14 23:59:04 EDT 2009


Thanks all for the responses. I was trying to grapple how a
ReentrantReadWriteLock would solve my problem, completely skipping
over the more simple approaches. Brian's idea of an atomic "generation
identifier" seems to be working like a champ.

Norman

On Sun, Jun 14, 2009 at 5:37 PM, David Holmes<davidcholmes at aapt.net.au> wrote:
> Norman,
>
> There are many many ways to set this up. It could be as simple as checking
> if the current server has changed after a timeout - if so then someone did
> the change; if not then search for a new server yourself. It all depends on
> the exact semantics you want - eg whether the new server has to be known to
> be good before anyone else starts using it; and how long a "down" server is
> excluded from being used etc. A CountDownLatch used as a simple gate can be
> used to make other threads wait while a search is in progress, if you don't
> want to use the lock directly for this purposes. (Using a Semaphore seems
> tricky because you don't know how many threads may be waiting.)
>
> David Holmes
>
>> -----Original Message-----
>> From: concurrency-interest-bounces at cs.oswego.edu
>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Norman
>> Elton
>> Sent: Monday, 15 June 2009 2:37 AM
>> To: concurrency-interest at cs.oswego.edu
>> Subject: [concurrency-interest] Concurrency Architecture
>>
>>
>>
>> I've been using the java.util.concurrent classes over the past few
>> years, they've worked well for every circumstance I could throw at
>> them. Today, I've stumbled upon a case that I just can't figure out
>> how best to tackle.
>>
>> I've got a connection generator which builds and returns connections
>> to a server. In case of failover, I'm maintaining a list of possible
>> servers to which it can generate connections. My wrapper
>> getConnection() method takes this into account by first attempting a
>> connection to the "current" server. If that times out, it scans the
>> list for a new "current" server.
>>
>> Here's some pseudocode:
>>
>> public Connection getConnection() {
>>       try {
>>               return this.generator.getConnection();
>>       } catch (TimeoutException e) {
>>       }
>>
>>       synchronized(this.generator) {
>>               foreach (this.servers as curr_server) {
>>                       try {
>>                               this.generator.server = curr_server;
>>                               return this.generator.getConnection();
>>                       } catch (TimeoutException e) {
>>                       }
>>               }
>>       }
>>
>>       throw new Exception("Sorry, couldn't find a server");
>> }
>>
>> In this case, if three threads simultaneously call getConnection(),
>> they will all timeout and hit the synchronized block together. The
>> first one will identify a new server, but the other two have no way to
>> know that a new server has been identified. They each will loop
>> through the possible servers.
>>
>> I'm looking for some way for all threads to be able to call the first
>> part of the procedure (attempt a connection to the current server). If
>> that fails, then the first thread will attempt to find a new server,
>> while others wait for the result.
>>
>> I've dug through all the possible types of locks, nothing quite meets
>> the need. Of course, I could be wrong! Can anyone think of a good way
>> to tackle these requirements?
>>
>> Thanks!
>>
>> Norman
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>



More information about the Concurrency-interest mailing list