Hi Rick,
On Friday 12 January 2001 23:36, Rick Horowitz wrote:
> > > Here are my questions: (I only have a cursory understanding of
> > > Castor at this point, so please forgive me for any stupid
> > > questions):
> > >
> > > 1. I would like to use Castor to manage persistence of EJB BMP
> > > entity beans, given JAWS' inability at the moment to support
> > > dependent objects. An EJB with no dependent objects would have
> > > a single Castor persistent object associated with it, whereas
> > > an EJB with dependent objects would implement those dependent
> > > objects as Castor dependent objects. If I use an architecture
> > > like this, is it best to let Castor directly persist the EJBs,
> > > themselves, or is it better to store the data for an EJB in a
> > > separate Castor data object?
> >
> >I believe that EJB class shouldn't coincide with Castor data
> > object. EJB class should hold some data object internally,
>
> Why do you think this is preferred?
Because of the different nature of these two entities ;-)
In my view Castor data object should be serializable and should be
able to walk between beans and client. For me it's good and
convenient, and I love Castor for support of long transactions,
although Sun JDO specification doesn't imply such things.
Anyway, the nature of Java Data Object is expressed by the word
"data", and I don't see why data objects should be bounded to EJB
container.
The nature of EJB remote interface is expressed by the word "remote",
the nature of EJB implementation is expressed bythe word
"implementation". Don't you see that they differ from "data"? :-)
EJB implementation usually contains some server business logic,
and therefore some server-specific code and class fields, do you want
such data to be passed through network and such code to be present on
client? I believe that Castor data object should contain "universal"
business logic: fields and methods that can be called anywhere.
Okay, here is more simple and "material" argument: EJB implementation
instances are managed by EJB container, Castor data objects are
managed by Castor, you cannot make them share objects.
When that will be done, that will be called "Castor CMP" :-)
> >use Castor
> >db.load(), db.update(), db.create(), db.remove() to implement
> >jdoLoad(), jdoStore(), jdoCreate(), jdoRemove().
>
> What are jdoLoad() etc? Do you mean ejbLoad() etc.?
Yes, sorry, jdoLoad etc are from Castor's Persistent interface,
I worked with Castor too much :-)
> >In general independent Castor data objects may not correspond to
> > some BMP, but only if you need BMP for some non-trivial remote
> > operations, some business logic performed for one object
> > instance. Otherwise you can use Castor data objects from Session
> > Beans or even from other Entity Beans directly, without
> > intermediate BMP (it would be faster BTW).
>
> Yes, I understand what you're saying. What I'm thinking is that by
> tying Castor data objects to BMPs, that should I want to do so in
> the future, I would have an easier time porting to EJB 2.0 CMP.
> Would you agree?
Yes, if you will keep in mind all the time that you shouldn't use
Castor capabilities that go beyond CMP 2.0 capabilities :-)
Seriously, if you want to use Castor JDO + BMP just as a temporary
replacement for CMP 2.0, I think you can achieve this goal and then
have relatively easy porting. But I believe that Castor JDO + BMP
gives you more flexible tool and more fast implementation than
CMP 2.0.
> >Even if you have two BMPs "hosting" two Castor data objects, you
> > can use Castor data object from "foreign" BMP.
> >In other words, I believe that it is okay to separate some Entity
> >into two classes, BMP as a remote object and JDO as a value
> >object. For me it is better approach than to claim that Entity ==
> >EntityBean and then to solve performance and network traffic
> > problems inventing various unclear tricks.
>
> Just to make sure I understand what you're saying, please look at
> an example with me. The example has 2 BMPs, A-BMP and B-BMP, backed
> by Castor data objects A-Castor and B-Castor, respectively, and if
> A-Castor references B-Castor. I load A-BMP from the database
> through an EJB finder method. If I call A-BMP.getB(), in an all
> EJB world, I would want it to return B, the remote interface to
> B-BMP. If the A-BMP's getB() method delegates to A-Castor's getB()
> method, I would get a reference to the B-Castor object. If
> B-Castor is serializable, then I suppose this is workable, however,
> it breaks the EJB semantics by returning a (possibly serializable
> object), when what I want is a remote EJB reference to B-BMP.
If this is what you want, then you can do the following:
1) use A-Castor's getB() to get B-Castor and then get its PK value.
2) use B-BMP findByPrimaryKey method to get B-BMP
This will not cause an additional database operation due to Castor's
cache - B-Castor will be loaded from the database only once.
> Thinking aloud here, it seems that this could be solved by loading
> A-BMP's reference to B-BMP in A-BMP's ejbLoad() method (and
> likewise with ejbStore()), and by not delegating the A-BMP.getB()
> method to A-Castor. Does all this sound correct to you? Do you
> see any reasons that I should not do this, aside from performance?
If the relation of A to B is N:1 or 1:1 then of course you can get
the value of B's primary key as A's field - this is the simplest way.
But if the relation is 1:N, you will need to write EJB finder method
in B-BMP, which finds all B for the given A, probably this method
should work directly via JDBC. I don't see any problems here.
Alternatively you can load all B-Castor objects for the relation
via Castor, get their primary key values and use findByPrimaryKey to
get all B-BMP references.
The first way is faster with the current version of Castor (some
things are going to be optimized in the future Castor release, then
the second way will become faster).
> > > 2. I would like to avoid duplicating data objects as much as
> > > possible. One thing that I've noticed with the whole J2EE
> > > architecture is that there is a lot of opportunity to duplicate
> > > objects that do roughly, or exactly, the same thing. For
> > > example: a) Struts uses JavaBeans that extend
> > > org.apache.struts.action.ActionForm to pass data from an HTML
> > > form in a JSP to the servlet for processing. In addition, both
> > > these and other, non-ActionForm JavaBeans are used to pass data
> > > back to a JSP for output to the user.
> > > b) It is recommended that data objects be used to pass bulk
> > > data between the EJB client and the EJB in order to minimize
> > > network and transaction overhead. Question: is it a bad idea to
> > > use Struts ActionForm beans as these data objects? The
> > > tradeoffs seem to be: if yes, then it increases the coupling
> > > between the EJBs and the front end technology - BAD, but if no,
> > > then it eliminates the need to implement and maintain an
> > > additional data object for the EJB. Opinions?
> >
> >I would use Castor data objects: you can pass them to client or to
> >servlet, then return them back (so called "long transaction") and
> >update in the database. Moreover, Castor supports dirty checking
> > for long transactions.
>
> Is it the case that Castor "long transactions" use 2 transactions,
> the first one does not lock the object(s) in quesiton and the 2nd
> does? If so, is this possible in an EJB CMT situation, in
> particular JBoss? Doesn't JBoss require setting of the commit
> level (which would control locking) on a per container basis,
> meaning a per EJB basis? Can this be handled (if it is indeed a
> problem) by simply allowing locking on both txns? Now you'll
> probably tell me that this is not at all how long transactions work
> :))
"Long transaction" use 2 transactions, you are right.
But both transactions use the default isolation level, provided by
container, they don't need to change it - just ordinary transactions.
If you use "db-locked" ("pessimistic") lock mode in Castor (it is for
"short" transactions), then the database write lock is put by means
of special RDBMS-specific constructs, e.g. "FOR UPDATE" in Oracle,
so Castor doesn't need to change properties of Connection,
the isolation level is being changed for the given record only.
I don't think that this contradicts to EJB specification or to JBoss
requirements.
Regards,
Oleg
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
