> [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".
