geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Summary?
Date Wed, 15 Mar 2006 00:35:52 GMT
David Blevins wrote:

> On Mar 14, 2006, at 12:55 AM, Jules Gosnell wrote:
>> David Blevins wrote:
>>> On Mar 9, 2006, at 5:59 AM, Jules Gosnell wrote:
>>>> David Blevins wrote:
>>>>> Sorry, was referring to this thread.  Seems like it's winding   
>>>>> down  and just looking for a clear idea of what the current   
>>>>> thinking is.
>>>> David,
>>>> since you are here - a few SFSB questions...
>>>> what provisions does the EJB spec make for timing out of SFSBs,  
>>>> if  any ? what metadata does this require associated with each  
>>>> session ?
>>> What I can recal is that you can't passivate a stateful bean in  
>>> mid- transaction.  You must activate a stateful bean if a client  
>>> attempts  to invoke it and the instance has not yet been timed  
>>> out.  And unlike  Entities, Stateful session bean data isn't  
>>> required to survive a  server crash or restart.
>>>> what provisions/requirements over and above these does OpenEJB  
>>>> make/ have ?
>>>> Aside from lifecycle management, retrieval and timing out, what   
>>>> other requirements might OpenEJB have for SFSB management ?
>>> Nothing I can think of.  Maybe you are looking for something very   
>>> specific.
>> I'm wondering how SFSBs are timed out. Does the spec describe this  
>> or is it container-specific ? Is the time-to-live on a per bean  
>> instance, type or container-wide basis ?  I'm trying to get a  
>> clearer picture of how we might unify web and ejb session  
>> lifecycles, so that they can be managed in a single component,
> The most specific the spec is on timing out is that "the Deployer  
> configures" it.  It's completely implementation specific and it's  
> pretty much just required that someone be allowed to set it, whatever  
> it is and however it may work.
>>>> Are Local SFSBs to be considered Serialisable/Passivatable/  
>>>> Migratable or not ?
>>> I think you may be thinking that a client using a Local vs Remote   
>>> interface to access a stateful bean has a different impact on the   
>>> stateful bean's lifecycle.  The lifecycle is the same regardless  
>>> of  how a client accesses it.  In other words, there is no such  
>>> thing as  a local or remote bean, just local or remote reference  to 
>>> beans.
>> I'm thinking that use of a Local interface relaxes the constraint  on 
>> params being passed through it being Serialisable. This implies  that 
>> the SFSB the other end may be asked to store non-Serialisable  data. 
>> If it does, this would preclude it from being involved in  operations 
>> like passivation and migration....? But, if the activate/ passivate 
>> part of the lifecycle is required of Local SFSBs as well,  then 
>> perhaps this is not an issue ?
> Again, wether the stateful bean is accessed via Local vs Remote  
> interface has zero affect or implications on the bean instance and  
> it's lifecycle  rules.  In all cases it's the bean's responsibility  
> to ensure that it's non-transient fields are serializable or one of  
> the container-provided objects (datasource refs, UserTransaction,  
> home objects, local or remote objects, etc).
>>>> Would it be simple to change OpenEJB to use an SFSB handle that   
>>>> included an ID to a 'SuperSession' (Object containing all  Session  
>>>> objects pertaining to a single client for a given  Server) along  
>>>> with an ID to particular 'SubSession' (The SFSB  itself) within 
>>>> this  'SuperSession', instead of whatever scheme  you currently use ?
>>> That wouldn't be simple as we don't have any concept of  
>>> provisioning  client ids aside from the optional security identity  
>>> associated with  incoming calls.  In general the spec isn't really  
>>> strict on the  server's view of a client, it's more focused on a  
>>> client's view of a  bean (e.g. server).  That is to say, beans  have 
>>> strict and spelled  out identity rules whereas client's do not.
>>> We could invent a universal client id concept but it would be a  
>>> fair  amount of work to reconcile that concept across the various  
>>> ways  people can invoke stateful beans; IIOP+IDL, IIOP+Remote  
>>> interface,  Custom protocol + Remote interface, Local interface.   
>>> Using just  Local interfaces, is the client id:
>>>  - The id of the servlet or ejb
>>>  - The id of the war or ejb-jar
>>>  - The id of the ear (if there is one)
>>>  - The id of the VM
>>> Remote interfaces really get you in trouble as they have the same   
>>> questions, plus they can be invoked by j2ee app clients as well  as  
>>> non-j2ee java clients, or even non-java clients via IDL/IIOP.
>> exactly - there is a can of worms here, which I think we are  
>> glossing over...
>> I've been giving some thought to how SFSB keys/ids/handles might  
>> work in a way that would allow them them to be colocated in a  
>> SuperSession... It is tricky because of the multiple ways in which  
>> they might be accessed. I think this needs careful thought and  
>> discussion. If provisioning of these keys is not easily isolated  
>> from the rest of OpenEJB then I think we will have problems here...
> Provisioning of the actual stateful session bean keys is easy to  
> isolate, but as I say inventing a client id that you could use as  
> part of a stateful session bean's id is not easy.
OK - great - thanks for all the clarifications...

>>> I guess I'm not sure at what level you are thinking when you say  
>>> the  word "client" or what you'd be looking to get out of the  concept.
>> anyone addressing one or more SFSBs via the EJB containers services.
> I was hoping for something more concrete and not more abstract :)   
> "Anyone" is way too vague to be useful.  As i say, what is most  
> effective for your purposes?  At least a finger in the wind would be  
> helpful to get my brain around what level you may need.  I.e. is a  
> client a component, or the application the component resides in, or  
> the VM the application resides in, or the user driving the  
> application...?

Ah - sorry, I think I see what you are driving at... - I was talking 
about 'clients' in the context of Session colocation - so I should have 
been more explicit and said 'User'.

The idea is one that I have had in mind for some time and the proposed 
Session API has adopted - that Geronimo should try to maintain the 
colocation of Sessions that are related. So if a WebSession moves from 
box A to box B we may want to move related SFSBs as well... By storing 
all related Sessions in the same object, we can ensure that this happens.

The problem will be deciding which sessions to group together.

Provided that there was only one usecase, things would be pretty 
straightforward - in a simple scenario, SFSBs could just be grouped by 
User. However when we get mixed usecases, things become more tricky - 
perhaps instances of the same SFSB being used by both external 
fat-clients aswell as threads from the web-container... Perhaps there is 
a way to map threads related to a particular WebSession in the web tier 
to a particular unique 'User' in the EJB tier ? Where cross-context 
dispatch needs to be supported in the web tier, rather than a single 
WebSession mapping to an EJB User, all WebSessions using the same 
SessionID will need to map to the same 'User' - I guess we just need to 
ensure that we can identify colocation relationships in each tier and 
map them to a common representation across all tiers... whether that 
representation is a User or something else is an open question...

I haven't given this serious thought yet - just flagged it as requiring 
further consideration...

My understanding is that the proposed Session API will leave this sort 
of decision to the container using it, whereas I want WADI to present 
the same API to client-containers whether colocation is being enforced 
or not... This probably means that I need to think about it a little 
harder :-)

I hope that answers your question ?


> -David

"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * Open Source Training & Support.

View raw message