Mohammad Nour El-Din wrote:
> Sounds good to me, but how this version is going to be shared among all
> servers ?

The client is usually sticky to a particular server (EJB by nature
enforces this), therefore it doesn't matter.  The client only cares
about the version number with reference to the server its speaking to.

If a client needs to fail-over to a new server, it will get a new list
and version number...so I believe it works...but good question
nevertheless. ;-)

Jeff

> 
> On 6/12/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>
>> Ok...so now that we have passed the TCK...I can get back and concentrate
>> on some fun stuff, so I wanted to bring up the old discussion again of
>> getting a clustering API pinned up on OpenEJB.  The whole idea on this
>> is to allow different clustering components to tie into the product.
>>
>> Before I stopped and did TCK testing, I got as far as adding the ability
>> to handle multiple URLs in the client/server to allow for failover.
>>
>> Now that I am getting back to the meat of the design here, I wanted to
>> go over at a high level of the direction I am taking this.
>>
>> 1) The client need to get an initial list of servers in the cluster.  I
>> assume this can occur during the first initial context handshake.
>>
>> 2) A version number is applied and sent along with the list.
>>
>> 3) Every time the client speaks to the server is sends along the version
>> number.  If the version is different, the server sends down a new list,
>> along with the new version number.
>>
>> 4) The server updates the list only when the servers in the cluster have
>> changed.
>>
>> Thoughts and comments?
>>
>> Jeff
>>
> 
> 
> 

Reply via email to