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