I'm a relational kinda guy (ObjectSpace, not ObjectStore), so I'll let
somebody else with OODB expertise address these....
> -----Original Message-----
> From: Javier Deniz [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 07, 1999 11:24 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Seduction by perceived ease of use,was RE: Granularity
> of EJBObj ects
>
> > [Chip Wilson]
> > If EBs do not partition the object graph, then I could have
> two EBs
> > resident in memory simultaneously, of different EB classes, and with
> > different PKs, running in different transaction contexts, but whose
> > underlying persistent representation is not completely disjoint. The
> server
> > will not be able to manage updates to this data, and the EBs will step
> on
> > each other's changes.
>
> Isn't it there were integration between OODBMS and EJB comes into play
> or am I missing something?
>
> Let me try to get wet with this. Please correct me (this is a bit of new
> land for me). In the following scenarios
> * ODB stands for an OODBMS containing a complex graph of business
> objects,
> * EB1 and EB2 are two entity bean objects of different types (I don't
> think it would make a different if they are of the same type; please
> comment)
> * SB1 and SB2 are session beans that receive the request from the
> client and use EB1/2's services as the only way to acess the ODB. An EJB
> txn takes place since a method is called (on SB1 or SB2) until that same
> method returns.
> * C1, C2, etc. are clients that call methods of SB1 and SB2.
>
> Scenario 1
> ------------
> There is NO integration between OODBMS and EJB server.
> EBs are not used at all.
> SB1 receives a method call (there is an EJB txn in place). SB1 starts an
> ODB txn to able to access/update objects in ODB.
> At the same time SB2 receives a method call (another EJB txn is set up).
> SB2 starts another ODB txn and acess/modify objects in the ODB.
> The EJB txns are independent of the ODB txns. The txn context is not
> propagated in calls affecting the ODB.
> This case is like 2 clients accessing an OODBMS. The EJB txns are not of
> much use. Are they?
> I have tried something like this scenario but not really tried enough to
> make sure that all that happens as I said above. Please correct.
>
> Scenario 2
> ------------
> There is integration between the OODBMS and the EJB server. I suppose
> this is what we have when using GemStone (EJB server + OODBMS) or
> Weblogic+VersantEJBContainer, for example.
> C1 calls a method in SB1 and C2 calls a method in SB2 "at the same
> time".
> SB1 calls a method in EB1 and SB2 calls a method in EB2. Both EB1 and
> EB2 "touch" the object model stored in ODB. The txn context is
> propagated from SB1 to EB1 to the ODB. A different txn context is
> propagated from SB2 to EB2 to ODB. The same ODB is touched by both txns
> but the txns make ensure the ACID properties hold. Therefore, if the
> same object (or page depending on the locking strategy of the OODBMS) is
> "touched" by both txns (now there are just 2 and not the 4 of scenario
> 1), then one of them wait for the other or fails while still one of them
> succeed.
>
> If I have well understood, the scenario by Chip Wilson above is more
> like scenario 1 (Please, correct me).
>
> If we had scenario 2 (i.e integration), then it would be impossible that
> "the EBs will step on each other's changes" and everything runs smooth
> even if both EBs "start from" different PKs but then "use/touch" the
> same object of the underlying object graph. To be honest, I still cannot
> see well the role of the PK in all this. I have tried to see them like
> entry points like roots in OODBMS terms but they still look to me like
> "too RDBMS oriented" like if EJB were not designed to deal with OODBMSs
> at all but I may be wrong. Are they "roots" or "logical object
> identifiers" in OODBMS terms? Otherwise, are they intended to be
> "business" ids just like the unique number of my account in my bank? In
> that case, it would still be just an entry point to the graph but who
> knows which objects are accessed next.
>
> I may be missing quite a few things in all this. I hope I am not
> confusing anybody here. Please, wait for replies to this email before
> taking any notes. If you can point me to further docs/discussions, it
> would be great as well.
>
> Javier
>
> ==========================================================================
> =
> 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".
