Ping to Dain and David Blevind

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Ping to Dain and David Blevind

Jeff Genender-4
Hey guys,

Any chance of getting those entry points in openejb posted for the cut
in to inject the clustering?  I am getting close to needing those ;-)

Jeff

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Ping to Dain and David Blevins

dblevins
Administrator
On Jul 7, 2006, at 9:04 AM, Jeff Genender wrote:

> Hey guys,
>
> Any chance of getting those entry points in openejb posted for the cut
> in to inject the clustering?  I am getting close to needing those ;-)

Happy help with something, but not sure what you're asking.

-David



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Ping to Dain and David Blevins

Jeff Genender-4
Cool.

Last week I spoke with Dain about injection points in openejb for where
we can hook up clustering.  He sent an email to the openejb lists
stating you and he will craft up and email explaining where the right
places are to get clustering in (i.e. which objects in OpenEJB) as well
as the todos (i.e. sniff for a session id etc).

I am getting close to having something and I wanted to begin wiring it
into openejb ;-)

Thanks!

Jeff

David Blevins wrote:

> On Jul 7, 2006, at 9:04 AM, Jeff Genender wrote:
>
>> Hey guys,
>>
>> Any chance of getting those entry points in openejb posted for the cut
>> in to inject the clustering?  I am getting close to needing those ;-)
>
> Happy help with something, but not sure what you're asking.
>
> -David
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)

dblevins
Administrator
The biggest TODO as far as session id would be to decide on what it  
is.  Namely, is it:

- one session id per client vm
- one session id per client connection
- one session id per login (security scoped)
- one session id per remote ejb proxy

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.

-David

On Jul 7, 2006, at 10:43 AM, Jeff Genender wrote:

> Cool.
>
> Last week I spoke with Dain about injection points in openejb for  
> where
> we can hook up clustering.  He sent an email to the openejb lists
> stating you and he will craft up and email explaining where the right
> places are to get clustering in (i.e. which objects in OpenEJB) as  
> well
> as the todos (i.e. sniff for a session id etc).
>
> I am getting close to having something and I wanted to begin wiring it
> into openejb ;-)
>
> Thanks!
>
> Jeff
>
> David Blevins wrote:
>> On Jul 7, 2006, at 9:04 AM, Jeff Genender wrote:
>>
>>> Hey guys,
>>>
>>> Any chance of getting those entry points in openejb posted for  
>>> the cut
>>> in to inject the clustering?  I am getting close to needing  
>>> those ;-)
>>
>> Happy help with something, but not sure what you're asking.
>>
>> -David
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)

bdudney

> 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.

> - 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).

> - 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.

TTFN,

Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html

> -David
>
> On Jul 7, 2006, at 10:43 AM, Jeff Genender wrote:
>
>> Cool.
>>
>> Last week I spoke with Dain about injection points in openejb for  
>> where
>> we can hook up clustering.  He sent an email to the openejb lists
>> stating you and he will craft up and email explaining where the right
>> places are to get clustering in (i.e. which objects in OpenEJB) as  
>> well
>> as the todos (i.e. sniff for a session id etc).
>>
>> I am getting close to having something and I wanted to begin  
>> wiring it
>> into openejb ;-)
>>
>> Thanks!
>>
>> Jeff
>>
>> David Blevins wrote:
>>> On Jul 7, 2006, at 9:04 AM, Jeff Genender wrote:
>>>
>>>> Hey guys,
>>>>
>>>> Any chance of getting those entry points in openejb posted for  
>>>> the cut
>>>> in to inject the clustering?  I am getting close to needing  
>>>> those ;-)
>>>
>>> Happy help with something, but not sure what you're asking.
>>>
>>> -David
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe from this list please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)

Dain Sundstrom
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.

>> - 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

Reply | Threaded
Open this post in threaded view
|

Re: Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)

bdudney
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
>


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Ping to Dain and David Blevind

bdudney
In reply to this post by Jeff Genender-4
Hi Jeff,

org.openejb.cache

and

org.openejb.cluster

seem to be the only two packages that have caching and clustering related code.

Folks more familiar with the code base: any other spots to dig into?

Thanks,


On Jul 7, 2006, at 10:04 AM, Jeff Genender wrote:

Hey guys,

Any chance of getting those entry points in openejb posted for the cut
in to inject the clustering?  I am getting close to needing those ;-)

Jeff

---------------------------------------------------------------------
To unsubscribe from this list please visit:



Reply | Threaded
Open this post in threaded view
|

Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)

dblevins
Administrator
In reply to this post by bdudney
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  
>> <[hidden email]> 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
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)

Bill Dudney
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  
>>> <[hidden email]> 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
>>>>
>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [openejb-dev] Clustering Session ID (Re: [openejb-dev] Ping to Dain and David Blevins)

dblevins
Administrator

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  
>>>> <[hidden email]> 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
>>>>>
>>>>>
>>>
>>
>