Javier Deniz wrote:
>
> 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.
--> If you maintain your own ODB txns in the sesssion-beans ... I would suggest
establishing the database connection on SB activation ..... and scoping each
transaction by a method. You still need to worry about txn propagation when
accessing other session beans (say, SB3) in a method on SB1 .... as the txn
context will not be automatically propagated. But ... this problem can always
be encountered even in the normal case ....for example when beans that may be
accessed from a different server. In that case ... the EJB server & database
should support distributed txns (support JTA).
>
>
> 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.
--> The EJB txns will be bound to ODB txns ... if the DD of SB1 and SB2 declare
TX_REQUIRED. The ODB container manages the txns transparently ... and
registers the txns with the EJB server coordinator.
>
>
> 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.
--> You are right .... the ODB has to provide txn isolation .... irrespective
of which part of the object graph is accessed by concurrent txns.
PKs may still be useful in the context of ODBs ... to find root objects. Unlike
as for RDBs ..... I will not advocate every small piece of data should be
mapped to entity-beans. In ODBs .... the user has the flexibility of
designating root objects from which the user applications would perform
searches. These root objects can then either be directly presented as
entity-beans to clients ..... or alternatively .... accessed by session-beans
that provide services that make use of the object-graphs.
An example would be an XML document .... that may comprise of several small
objects (nodes) when stored in the database .... but to the client application
... presented as a single entity-bean. Also .... session-beans could present
document-management services for the XML documents. You would get the best of
both worlds ...... fine-grained access to persistent objects on the server
..... & coarse grained services for client applications.
cheers,
- Nipun
>
> ===========================================================================
> 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".
