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 Thu, 09 Mar 2006 13:59:51 GMT
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 provisions/requirements over and above these does OpenEJB make/have ?
I seem to remember that SFSBs need notification on 
activation/passivation ? is this correct ? are any other notifications 
required ?
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 ?
Aside from lifecycle management, retrieval and timing out, what other 
requirements might OpenEJB have for SFSB management ?
Are Local SFSBs to be considered Serialisable/Passivatable/Migratable or 
not ?

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 ?

looking forward to some interesting answers...


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


Mime
View raw message