Javier,
Some comments on "graphs of objects" and transactions, EJB references...
-Chris.
> -----Original Message-----
> From: Javier Deniz [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, July 30, 1999 6:14 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Hanlding EB relationships,was RE: fat getter/setters
> versusget/ set with all data
>
>> snip
> > 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?
>
I don't think it matters where the physical persistence is. Could be OR
mapped or OODBMS (transaction issues are the same).
> In the second case, I think it is not much different than a
> session bean "using" an entity bean. Is it?
>
True.
> In the first case (persistent OODBMS objects referencing an entity
> bean), it looks odd to me but I suppose it is possible.
>
Part of the trick is that the EJB reference itself is transient, so you
swizzle the EJB reference to a Key reference at commit time.
<vendor>
In GemStone/J PCA you would do this by making the EJB reference a transient
variable (and therefor never persisted), but the Key ariable would not be
transient. The getter for the EJB reference member would swizzle Key to
reference (via Home lookup) when it finds that the reference is null.
</vendor>
> 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.
>
Incorrect. It would be unfortunate to be forced into bean managed
transactions in order to use native persistence. This makes it difficult to
implement caching schemes with ACID properties (we see a lot of this use
case).
<vendor>
GemStone/J integrated PCA transactions with EJB transactions. The way this
works is we provide transaction Resource wrappers for PCA (and JDBC)
connections. These Resource wrappers no how to participate in the EJB
servers 2PC...
</vendor>
> 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
>
<vendor>
Again, in GemStone/J you wouldn't break it down this way. PCA transactions
will play with the EJB transactions... So an EJB transaction could involve
JDBC and PCA objects and we get ACID properties at the EJB transaction
level.
</vendor>
> 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".
===========================================================================
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".
