Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44168519.5020903@coredevelopers.net>
Date: Tue, 14 Mar 2006 08:55:53 +0000
From: Jules Gosnell <jules@coredevelopers.net>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Summary?
References: <1F5F68F5-2E35-4AAF-B90B-072081D34FE7@gmail.com>
 <44042DE9.2080203@mortbay.com>
 <F10E5C28-9354-4C62-84B8-2FA718F27720@iq80.com>
 <4406A4CA.7080501@mortbay.com>
 <8BD915E8-7E9B-423C-BAE0-30848C10DA49@iq80.com>
 <440855A4.4060406@mortbay.com>
 <50B7DE47-82DB-4F5B-AD61-2B2AACC1AE35@iq80.com>
 <440BF78E.2000802@mortbay.com>
 <79A344F8-8D67-4957-81FD-A1698EC86101@iq80.com>
 <C23DD45A-4ACB-4A9A-AB10-E5CBAD01E7D7@visi.com>
 <441034D7.3030809@coredevelopers.net>
 <E1AFB934-5882-4D5F-9F39-9A29B0D92D61@visi.com>
In-Reply-To: <E1AFB934-5882-4D5F-9F39-9A29B0D92D61@visi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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