javier writes:
> snip
> 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)
>
True
> * 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.
>
You got it. It would be pretty useless to wrap an OODB in EJB and not
integrate
the transaction models. Then again it would be pretty useless to wrap any
datastore
in EJB and not integrate the transaction models. Not a recommended
configuration
from where I sit (then again I represent a vendor with the usual evil
intentions ;-)
> 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).
>
I lost the flow of this thread. Not sure what you are getting at here.
> 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.
>
PK's are a bit kludgy for oodb's, but getting at a root of a graphs by a
"key" is
a useful thing. You are correct that EB's reflect a relational view of
things. I guess
you can't moon Oracle ;-)
But seriously, there is a lot more data in RDBMS than oodb. That's why we
support
both.
> 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".
