You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Bill Dudney <bd...@apache.org> on 2006/07/12 14:45:41 UTC
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)
Hi Dain,
Thanks for the response, my response inline...
(for anyone getting this twice, sorry I sent to both the incubator
list and the old codehaus list)
On Jul 10, 2006, at 10:20 PM, Dain Sundstrom wrote:
> On Jul 10, 2006, at 8:43 PM, Bill Dudney wrote:
>
>>
>>> The biggest TODO as far as session id would be to decide on what
>>> it is. Namely, is it:
>>>
>>
>> I'm still a newbie to the code base so I don't fully understand
>> all the ramifications of the following choices but here are some
>> of my thoughts from the session-api/caching impl perspective.
>>
>> I have a short write up of the current caching impl that can be
>> found here;
>>
>> http://cwiki.apache.org/GMOxDEV/caching.html
>>
>> which drives many of my comments below.
>>
>> Basically, the finer grained the session-id the less contention
>> there would be in the cache.
>
> Say what? Contention is caused when two+ parties attempt to access
> the same data. IMO you want to choose the biggest grain size where
> you will have little or no contention, because small grain size
> comes at the cost of extra book keeping and locking. In our case,
> since the data in the session is for a single client and is
> naturally partitioned there will never be any contention by
> definition.
I am thinking along the lines of two threads trying to read/write to
the same key at the same time. Perhaps we are thinking about the same
thing? The reason smaller is better in the current impl is that the
locking happens on a per key basis. So if the sessionid were on a per
client VM (lets say web app vm for example) level each 'user' or
'client' in the client vm would be locking the whole session from
other 'users' within that VM while the session is being updated.
With a smaller scope of the session id (i.e. one session id per
remote ejb proxy for example) there would be less chance of two
clients trying to read/write from the same locked resource.
What don't I get?
>
>>> - one session id per client vm
>>
>> With the current caching impl outlined above this solution would
>> cause lots of contention. Each write would cause the whole client-
>> vm part of the cache to be locked (i.e. the lock is on the key).
>
> Assuming that a client vm has more than one user. In general, this
> is a good strategy for J2ee app clients but a poor choice for multi
> user vms (web apps).
>
>>> - one session id per client connection
>>> - one session id per login (security scoped)
>>> - one session id per remote ejb proxy
>>
>> This would cause the least amt of contention since the session-id
>> would lock only the data for the particular remote object.
>>
>>>
>>> Or some other option i haven't considered.
>>>
>>> Thoughts?
>>>
>>> The per connection option seems attractive though it would
>>> require some code change as we don't currently support a keep-
>>> alive concept.
>>>
>>
>> I'd prefer to keep the initial code changes to a minimum just to
>> get something working.
>
> me 2 :)
>
> -dain
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)
Posted by David Blevins <da...@visi.com>.
On Jul 15, 2006, at 9:44 PM, Bill Dudney wrote:
> Here are the original 4 options that you posted (I numbered them
> for reference);
Might be more options, just posted what was immediately in my head.
>> (1)- one session id per client vm
>> (2)- one session id per client connection
>> (3)- one session id per login (security scoped)
>> (4)- one session id per remote ejb proxy
>
> I prefer 4 because it will work best with what I expect to be the
> most typical use case (but I could be wrong so please point out
> better info if I am). Typical being a web app connected to the ejb
> tier.
Certainly 4 is the finest grain session id you could get. It would
literally mean that each session bean instance is clustered
independently with no concept of affinity or awareness of who "owns"
it be that a webapp or plain java client.
If this were a web container that'd be simple as a "client" can only
have one session. Obviously with ejb though a client can have
multiple session beans so things may get hairy.
> Although 3 is probably close enough to 4 that it would not cause
> conflict in the items in the cache being locked. I think both 1 and
> 2 would cause lots of conflict in what is being locked.
It's relative really. More on that below.
> Now I'm full of questions :-)
>
> What are the motivations/benifits/costs WRT the current openejb
> code base WRT the 4 options?
> How is the sessionid concept currently implemented (if at all)?
The current sessionid concept if for tracking session bean instances
and has no awareness or concept of who "owns" a session bean
instance. You could cluster around that sessionid, but without some
sort of id to track the "owner", when a fail-over occurs each
instance would be treated as one unit and the "owner" may end up with
bean references now across a few different servers.
> Do you have a preference one way or the other? (as was said earlier
> less code change is better, at least in the beginning :)
If you wanted to get started with simply clustering on session bean
ids individually, that'd certainly involve very little code change.
Definitely, though, for an optimal clustering scenario that still
works after a fail-over, you want to end up with all the client's
data in the same place, so you'll still need to define what a
"client" is. That's where the relativity comes in.
For an standalone java app using ejbs, the "client" id could very
well be some static it's VM. For the situation of a webapp, the
client is not the server vm but the closest thing that represents the
client connected to the vm, which is likely the servlet session.
As for how to pull that off, that's where the real work is. Your
guess is as good as mine.
-David
> TTFN,
> -bd-
>
> On Jul 14, 2006, at 4:43 PM, David Blevins wrote:
>
>> The question hasn't been answered at a concrete level I was
>> looking for. To play along... the session id is tied to the
>> "client", fine. What is a client and how do we identify one? ;)
>>
>> -David
>>
>> On Jul 12, 2006, at 8:56 AM, Jeff Genender wrote:
>>
>>> Ok...then I think we are in agreement then here ;-)
>>>
>>> Bill Dudney wrote:
>>>> Hi Jeff,
>>>>
>>>> That might be the current impl. But this whold thread was to
>>>> discuss what the session id should be.
>>>>
>>>> I'm trying to say that of the 4 options presented at the root of
>>>> this thread I'd prefer that the session ID be tied to the
>>>> particular client which would lead to the smallest glob of stuff
>>>> that gets locked.
>>>>
>>>> if we go with the first option (again from the root of the
>>>> thread) we would have a session id per client vm, that is what I
>>>> don't want.
>>>>
>>>> -bd-
>>>>
>>>> On Wednesday, July 12, 2006, at 11:36AM, Jeff Genender
>>>> <jg...@apache.org> wrote:
>>>>
>>>>>
>>>>> Bill Dudney wrote:
>>>>>> If the seesion id is tied to the client vm, i.e. the web vm
>>>>>> then there is one session id per web tier vm (which in all
>>>>>> likelyhood has many many users).
>>>>>>
>>>>> Hmmm...I don't think I agree here. I believe the session id is
>>>>> tied to
>>>>> the client...period. There is one id per session per
>>>>> client...not web
>>>>> tier vm. Maybe you can explain what you are thinking?
>>>>>
>>>>> Its my understanding the session id is like a web session...that
>>>>> particular client gets a unique id that represents only that
>>>>> session for
>>>>> that client.
>>>>>
>>>>> Jeff
>>>>>
>>>>>
>>>
>>
>
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)
Posted by Bill Dudney <bd...@mac.com>.
Hi David,
Thanks for jumping back in.
Here are the original 4 options that you posted (I numbered them for
reference);
> (1)- one session id per client vm
> (2)- one session id per client connection
> (3)- one session id per login (security scoped)
> (4)- one session id per remote ejb proxy
I prefer 4 because it will work best with what I expect to be the
most typical use case (but I could be wrong so please point out
better info if I am). Typical being a web app connected to the ejb
tier. Although 3 is probably close enough to 4 that it would not
cause conflict in the items in the cache being locked. I think both 1
and 2 would cause lots of conflict in what is being locked.
Now I'm full of questions :-)
What are the motivations/benifits/costs WRT the current openejb code
base WRT the 4 options?
Do you have a preference one way or the other? (as was said earlier
less code change is better, at least in the beginning :)
How is the sessionid concept currently implemented (if at all)?
TTFN,
-bd-
On Jul 14, 2006, at 4:43 PM, David Blevins wrote:
> The question hasn't been answered at a concrete level I was looking
> for. To play along... the session id is tied to the "client",
> fine. What is a client and how do we identify one? ;)
>
> -David
>
> On Jul 12, 2006, at 8:56 AM, Jeff Genender wrote:
>
>> Ok...then I think we are in agreement then here ;-)
>>
>> Bill Dudney wrote:
>>> Hi Jeff,
>>>
>>> That might be the current impl. But this whold thread was to
>>> discuss what the session id should be.
>>>
>>> I'm trying to say that of the 4 options presented at the root of
>>> this thread I'd prefer that the session ID be tied to the
>>> particular client which would lead to the smallest glob of stuff
>>> that gets locked.
>>>
>>> if we go with the first option (again from the root of the
>>> thread) we would have a session id per client vm, that is what I
>>> don't want.
>>>
>>> -bd-
>>>
>>> On Wednesday, July 12, 2006, at 11:36AM, Jeff Genender
>>> <jg...@apache.org> wrote:
>>>
>>>>
>>>> Bill Dudney wrote:
>>>>> If the seesion id is tied to the client vm, i.e. the web vm
>>>>> then there is one session id per web tier vm (which in all
>>>>> likelyhood has many many users).
>>>>>
>>>> Hmmm...I don't think I agree here. I believe the session id is
>>>> tied to
>>>> the client...period. There is one id per session per
>>>> client...not web
>>>> tier vm. Maybe you can explain what you are thinking?
>>>>
>>>> Its my understanding the session id is like a web session...that
>>>> particular client gets a unique id that represents only that
>>>> session for
>>>> that client.
>>>>
>>>> Jeff
>>>>
>>>>
>>
>
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)
Posted by David Blevins <da...@visi.com>.
The question hasn't been answered at a concrete level I was looking
for. To play along... the session id is tied to the "client", fine.
What is a client and how do we identify one? ;)
-David
On Jul 12, 2006, at 8:56 AM, Jeff Genender wrote:
> Ok...then I think we are in agreement then here ;-)
>
> Bill Dudney wrote:
>> Hi Jeff,
>>
>> That might be the current impl. But this whold thread was to
>> discuss what the session id should be.
>>
>> I'm trying to say that of the 4 options presented at the root of
>> this thread I'd prefer that the session ID be tied to the
>> particular client which would lead to the smallest glob of stuff
>> that gets locked.
>>
>> if we go with the first option (again from the root of the thread)
>> we would have a session id per client vm, that is what I don't want.
>>
>> -bd-
>>
>> On Wednesday, July 12, 2006, at 11:36AM, Jeff Genender
>> <jg...@apache.org> wrote:
>>
>>>
>>> Bill Dudney wrote:
>>>> If the seesion id is tied to the client vm, i.e. the web vm then
>>>> there is one session id per web tier vm (which in all likelyhood
>>>> has many many users).
>>>>
>>> Hmmm...I don't think I agree here. I believe the session id is
>>> tied to
>>> the client...period. There is one id per session per
>>> client...not web
>>> tier vm. Maybe you can explain what you are thinking?
>>>
>>> Its my understanding the session id is like a web session...that
>>> particular client gets a unique id that represents only that
>>> session for
>>> that client.
>>>
>>> Jeff
>>>
>>>
>
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to
Dain and David Blevins)
Posted by Jeff Genender <jg...@apache.org>.
Ok...then I think we are in agreement then here ;-)
Bill Dudney wrote:
> Hi Jeff,
>
> That might be the current impl. But this whold thread was to discuss what the session id should be.
>
> I'm trying to say that of the 4 options presented at the root of this thread I'd prefer that the session ID be tied to the particular client which would lead to the smallest glob of stuff that gets locked.
>
> if we go with the first option (again from the root of the thread) we would have a session id per client vm, that is what I don't want.
>
> -bd-
>
> On Wednesday, July 12, 2006, at 11:36AM, Jeff Genender <jg...@apache.org> wrote:
>
>>
>> Bill Dudney wrote:
>>> If the seesion id is tied to the client vm, i.e. the web vm then there is one session id per web tier vm (which in all likelyhood has many many users).
>>>
>> Hmmm...I don't think I agree here. I believe the session id is tied to
>> the client...period. There is one id per session per client...not web
>> tier vm. Maybe you can explain what you are thinking?
>>
>> Its my understanding the session id is like a web session...that
>> particular client gets a unique id that represents only that session for
>> that client.
>>
>> Jeff
>>
>>
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to
Dain and David Blevins)
Posted by Bill Dudney <bd...@mac.com>.
Hi Jeff,
That might be the current impl. But this whold thread was to discuss what the session id should be.
I'm trying to say that of the 4 options presented at the root of this thread I'd prefer that the session ID be tied to the particular client which would lead to the smallest glob of stuff that gets locked.
if we go with the first option (again from the root of the thread) we would have a session id per client vm, that is what I don't want.
-bd-
On Wednesday, July 12, 2006, at 11:36AM, Jeff Genender <jg...@apache.org> wrote:
>
>
>Bill Dudney wrote:
>>
>> If the seesion id is tied to the client vm, i.e. the web vm then there is one session id per web tier vm (which in all likelyhood has many many users).
>>
>
>Hmmm...I don't think I agree here. I believe the session id is tied to
>the client...period. There is one id per session per client...not web
>tier vm. Maybe you can explain what you are thinking?
>
>Its my understanding the session id is like a web session...that
>particular client gets a unique id that represents only that session for
>that client.
>
>Jeff
>
>
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to
Dain and David Blevins)
Posted by Jeff Genender <jg...@apache.org>.
Bill Dudney wrote:
>
> If the seesion id is tied to the client vm, i.e. the web vm then there is one session id per web tier vm (which in all likelyhood has many many users).
>
Hmmm...I don't think I agree here. I believe the session id is tied to
the client...period. There is one id per session per client...not web
tier vm. Maybe you can explain what you are thinking?
Its my understanding the session id is like a web session...that
particular client gets a unique id that represents only that session for
that client.
Jeff
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to
Dain and David Blevins)
Posted by Bill Dudney <bd...@mac.com>.
Hi Jeff,
On Wednesday, July 12, 2006, at 11:25AM, Jeff Genender <jg...@apache.org> wrote:
>
>
>Bill Dudney wrote:
>> Hi Dain,
>>
>> Thanks for the response, my response inline...
>>
>> (for anyone getting this twice, sorry I sent to both the incubator list
>> and the old codehaus list)
>>
>> On Jul 10, 2006, at 10:20 PM, Dain Sundstrom wrote:
>>
>>> On Jul 10, 2006, at 8:43 PM, Bill Dudney wrote:
>>>
>>>>
>>>>> The biggest TODO as far as session id would be to decide on what it
>>>>> is. Namely, is it:
>>>>>
>>>>
>>>> I'm still a newbie to the code base so I don't fully understand all
>>>> the ramifications of the following choices but here are some of my
>>>> thoughts from the session-api/caching impl perspective.
>>>>
>>>> I have a short write up of the current caching impl that can be found
>>>> here;
>>>>
>>>> http://cwiki.apache.org/GMOxDEV/caching.html
>>>>
>>>> which drives many of my comments below.
>>>>
>>>> Basically, the finer grained the session-id the less contention there
>>>> would be in the cache.
>>>
>>> Say what? Contention is caused when two+ parties attempt to access
>>> the same data. IMO you want to choose the biggest grain size where
>>> you will have little or no contention, because small grain size comes
>>> at the cost of extra book keeping and locking. In our case, since the
>>> data in the session is for a single client and is naturally
>>> partitioned there will never be any contention by definition.
>>
>> I am thinking along the lines of two threads trying to read/write to the
>> same key at the same time. Perhaps we are thinking about the same thing?
>> The reason smaller is better in the current impl is that the locking
>> happens on a per key basis. So if the sessionid were on a per client VM
>> (lets say web app vm for example) level each 'user' or 'client' in the
>> client vm would be locking the whole session from other 'users' within
>> that VM while the session is being updated.
>>
>> With a smaller scope of the session id (i.e. one session id per remote
>> ejb proxy for example) there would be less chance of two clients trying
>> to read/write from the same locked resource.
>>
>> What don't I get?
>
>I am agreeing with Dain here...how would there even be a possibility of
>2 parties hitting the same key...how would you have 2 threads trying ot
>read/write to the same key at the same time? How can you have more than
>1 user per session?
>
If the seesion id is tied to the client vm, i.e. the web vm then there is one session id per web tier vm (which in all likelyhood has many many users).
>>
>>>
>>>>> - one session id per client vm
>>>>
>>>> With the current caching impl outlined above this solution would
>>>> cause lots of contention. Each write would cause the whole client-vm
>>>> part of the cache to be locked (i.e. the lock is on the key).
>>>
>>> Assuming that a client vm has more than one user. In general, this is
>>> a good strategy for J2ee app clients but a poor choice for multi user
>>> vms (web apps).
>>>
>>>>> - one session id per client connection
>>>>> - one session id per login (security scoped)
>>>>> - one session id per remote ejb proxy
>>>>
>>>> This would cause the least amt of contention since the session-id
>>>> would lock only the data for the particular remote object.
>>>>
>>>>>
>>>>> Or some other option i haven't considered.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> The per connection option seems attractive though it would require
>>>>> some code change as we don't currently support a keep-alive concept.
>>>>>
>>>>
>>>> I'd prefer to keep the initial code changes to a minimum just to get
>>>> something working.
>>>
>>> me 2 :)
>>>
>>> -dain
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>
>
Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to
Dain and David Blevins)
Posted by Jeff Genender <jg...@apache.org>.
Bill Dudney wrote:
> Hi Dain,
>
> Thanks for the response, my response inline...
>
> (for anyone getting this twice, sorry I sent to both the incubator list
> and the old codehaus list)
>
> On Jul 10, 2006, at 10:20 PM, Dain Sundstrom wrote:
>
>> On Jul 10, 2006, at 8:43 PM, Bill Dudney wrote:
>>
>>>
>>>> The biggest TODO as far as session id would be to decide on what it
>>>> is. Namely, is it:
>>>>
>>>
>>> I'm still a newbie to the code base so I don't fully understand all
>>> the ramifications of the following choices but here are some of my
>>> thoughts from the session-api/caching impl perspective.
>>>
>>> I have a short write up of the current caching impl that can be found
>>> here;
>>>
>>> http://cwiki.apache.org/GMOxDEV/caching.html
>>>
>>> which drives many of my comments below.
>>>
>>> Basically, the finer grained the session-id the less contention there
>>> would be in the cache.
>>
>> Say what? Contention is caused when two+ parties attempt to access
>> the same data. IMO you want to choose the biggest grain size where
>> you will have little or no contention, because small grain size comes
>> at the cost of extra book keeping and locking. In our case, since the
>> data in the session is for a single client and is naturally
>> partitioned there will never be any contention by definition.
>
> I am thinking along the lines of two threads trying to read/write to the
> same key at the same time. Perhaps we are thinking about the same thing?
> The reason smaller is better in the current impl is that the locking
> happens on a per key basis. So if the sessionid were on a per client VM
> (lets say web app vm for example) level each 'user' or 'client' in the
> client vm would be locking the whole session from other 'users' within
> that VM while the session is being updated.
>
> With a smaller scope of the session id (i.e. one session id per remote
> ejb proxy for example) there would be less chance of two clients trying
> to read/write from the same locked resource.
>
> What don't I get?
I am agreeing with Dain here...how would there even be a possibility of
2 parties hitting the same key...how would you have 2 threads trying ot
read/write to the same key at the same time? How can you have more than
1 user per session?
>
>>
>>>> - one session id per client vm
>>>
>>> With the current caching impl outlined above this solution would
>>> cause lots of contention. Each write would cause the whole client-vm
>>> part of the cache to be locked (i.e. the lock is on the key).
>>
>> Assuming that a client vm has more than one user. In general, this is
>> a good strategy for J2ee app clients but a poor choice for multi user
>> vms (web apps).
>>
>>>> - one session id per client connection
>>>> - one session id per login (security scoped)
>>>> - one session id per remote ejb proxy
>>>
>>> This would cause the least amt of contention since the session-id
>>> would lock only the data for the particular remote object.
>>>
>>>>
>>>> Or some other option i haven't considered.
>>>>
>>>> Thoughts?
>>>>
>>>> The per connection option seems attractive though it would require
>>>> some code change as we don't currently support a keep-alive concept.
>>>>
>>>
>>> I'd prefer to keep the initial code changes to a minimum just to get
>>> something working.
>>
>> me 2 :)
>>
>> -dain
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>