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