geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Summary?
Date Tue, 14 Mar 2006 08:55:53 GMT
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,

>
>> I seem to remember that SFSBs need notification on activation/ 
>> passivation ? is this correct ? are any other notifications required ?
>
>
> A notification before a passivation (ejbPassivate()/@PrePassivate)  
> and another after activation (ejbActivate()/@PostActivate).
>
>> Is it possible for one client to pass the handle of an SFSB to  
>> another ? Does the spec touch on this ? Does it ever happen ?
>
>
> I know that per spec, the client identity cannot change mid- 
> transaction.  Aside from that we allow it.
>
>> 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 ?

>
>> and finally :
>>
>> 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...

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

>    That'd probably be the most productive way to look at the concept 
> --  otherwise it becomes one of those existentialist "what is a  
> component" type of things.
>
>> looking forward to some interesting answers...
>
>
> Hope they help!

of course ! Thanks.

Jules

>
> -David
>
>
>>
>>
>> Jules
>>
>>>
>>> -David
>>>
>>> On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
>>>
>>>> Looks good.
>>>>
>>>> -dain
>>>>
>>>> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>>>>
>>>>> Dain Sundstrom wrote:
>>>>>
>>>>>> My guess is we're going to need to add an event notification   
>>>>>> system  to
>>>>>> the Session APIs.  What do you think about just crib off of  
>>>>>> the   servlet
>>>>>> ones.  I think we could just smash the three session listener
>>>>>> interfaces into something like this:
>>>>>>
>>>>>> public interface SessionListener extends Listener {
>>>>>>     void valueBound(SessionEvent event);
>>>>>>     void valueUnbound(SessionEvent event);
>>>>>>     void attributeAdded(SessionEvent event);
>>>>>>     void attributeRemoved(SessionEvent event);
>>>>>>     void attributeRemoved(SessionEvent event);
>>>>>
>>>>>
>>>>>
>>>>> I think you mean:
>>>>>  void attributeReplaced(SessionEvent event);
>>>>>
>>>>>
>>>>>>     void valueBound(SessionEvent event);
>>>>>>     void valueUnbound(SessionEvent event);
>>>>>>     void sessionCreated(SessionEvent event)
>>>>>>     void sessionDestroyed(SessionEvent event)
>>>>>> }
>>>>>>
>>>>>> public class SessionEvent extends Event {
>>>>>>     Session getSession();
>>>>>>     String getName();
>>>>>>     String getValue();
>>>>>> }
>>>>>>
>>>>>> We would bind a listener with a method on the Locator:
>>>>>>
>>>>>>     void addSessionListener(SessionListener listener);
>>>>>>     void removeSessionListener(SessionListener listener);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> that would certainly do it - the only change I'd like to see
>>>>> is that the SessionEvent is
>>>>>
>>>>>
>>>>>  public class SessionEvent extends Event {
>>>>>      Session getSession();
>>>>>      String getName();
>>>>>      String getOldValue();
>>>>>      String getNewValue();
>>>>>  }
>>>>>
>>>>> As it is confusing for remove and replace what getValue() returns.
>>>>>
>>>>> Also as the bound/unbound events are actually called on the
>>>>> value itself, you need both old and new values so you can call
>>>>> unbind and bind during a replace.
>>>>>
>>>>> cheers
>>>>
>>>>
>>>>
>>>
>>
>>
>> -- 
>> "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)
>> *
>> *    www.coredevelopers.net
>> *
>> * Open Source Training & Support.
>> **********************************/
>>
>


-- 
"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)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message