Frank,
Note that my use of the term "session" has nothing to do with session
beans, not even with EJB. "session" is the term used in the paper I mentioned
(design patterns are usually helpful to add new vocabulary that
helps communication but it's true that some terms are overused, like
"session" in this case).
Those "session objects" I mention are just objects shared by many other
objects. You can see it as a centralized repository of "singletons" or
global variables. Such "session object" allows you to have a single
reference from the objects that share all those global variables.
Some business scenarios make take months or years. You may want to
have a single repository of data that is shared by the many objects
involved in that scenario. In that case, all the objects involved
need to be persistent and that includes the "session object", repository
of global variables, shared object, or whatever name may be more
convenient to describe that.
> I have another question that came up recently in our work:
> How about non-bean to bean relationships? We're all talking about
> bean to non-bean, but what if at the end of some graph of non-bean
> objects you want to have a refernce to a entity bean? What are the
> implications of that for persistence mapping and transactions?
Interesting, but I have not come accross to a situation like that.
Where is exactly the graph of objects. Are they persistent in an
OODBMS or just a graph of transient objects referenced from a session
bean? In the second case, I think it is not much different than a
session bean "using" an entity bean. Is it?
In the first case (persistent OODBMS objects referencing an entity
bean), it looks odd to me but I suppose it is possible. We know we
can have a session bean using directly persistent OODBMS objects but
transactions are not propagated unless the OODBMS txns and EJB txns can
work together (say by using a common distribution standard like JTA).
AFAIK, that is not happening yet in the available products. Therefore,
I think you would have 3 different independent transactions, namely:
* EJB txn when client calls session bean
* OODBMS txn when session bean uses OODBMS objects
* a different EJB txn when persistent object "uses" entity bean
There was a thread in May99 that included some discussion that may be
relevant here. You may want to have a look in the archives.
Here are some details of one of those messages that I think may help:
Subject: Re: Seduction by perceived ease of use,was RE: Granularity ofEJBObj
ects
Date: Fri, 7 May 1999 18:44:02 -0700
From: Nipun Sehgal <[EMAIL PROTECTED]>
Cheers,
Javier
Frank Sauer wrote:
>
> Session objects are never shared and are not meant to be persistent
> (though they do have an activation/deactivation mechanism in place
> for stateful session beans). A SessionBean always serves one client
> at a time. Stateless session beans may serve multiple clients but not
> simultaneously. A generally accepted architecture is the opposite of
> what you describe, namely session beans wrapping entity beans. It's
> the entity beans that are shared between multiple clients, not the other
> way around.
>
> I have another question that came up recently in our work:
> How about non-bean to bean relationships? We're all talking about
> bean to non-bean, but what if at the end of some graph of non-bean
> objects you want to have a refernce to a entity bean? What are the
> implications of that for persistence mapping and transactions?
>
> Frank
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Javier Deniz
> Sent: Thursday, July 29, 1999 9:14 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Hanlding EB relationships,was RE: fat getter/setters versus
> get/ set with all data
>
> Chris Raber wrote:
> > - Bean to dependent object. My opinion is that these are always
> aggregating
> > relationships. If a bean needs to relate to a non-bean object, which is
> does
> > not "own", then the dependent-object should probably be escalated to bean
> > status.
>
> I am not quite sure about that. Consider, for example, a Session object in
> the sense described by Yoder/Barcalow in their PLoP'97 paper "Architecture
> Patterns for Enabling Application Security" (to appear in PLoPD-4 book).
> Their "solution" section starts saying:
>
> Create a Session object, which holds all of the
> variables that need to be shared by many objects.
>
> Note that we may want persistent session objects which are referenced
> by many entity beans to hold shared values during long business scenarios.
> Those session objects are typically created once by some kind of
> administration utility and then used only by the entity beans that
> share the several values hidden in the session object.
> Wrapping session beans or clients do not access them in typical
> business situations. We think that making them beans adds unnecessary
> overhead. We would rather leave the OODBMS handle the access to such
> objects here. Adding "EJB access" wouldn't add much value here
> (would it?). Using a non-OO DB may be different, though.
>
> Javier Deniz
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
