Troy;
The #3 concept is fairly straight forward.
Essentially, once the entity bean has been created, it
makes no writes to the database until the transaction
it is running under commits. So if you were to make
the commit option of your entity bean REQUIRES NEW,
then it would write to the database right away because
as soon as the create method ends, the transaction
will attempt to commit.
Alternatively, if the entity bean was REQUIRES, and
you are fronting the entity bean with a sesison bean
which itself is also REQUIRES, then the transaction
begins in session bean, is continued in the entity
bean and terminates at the end of the call to the
session bean.
In this scenario, you are free to call create [and
postCreate] as well as a series of setX() methods
without having a write to the database made until you
are good and ready for it to do so.
For example:
client (eg. servlet)
calls session bean method foo() START TRANSACTION A
calls entity.Home.create IN TRANSACTION A
container calls ejbPostCreate IN TRANSACTION
A
calls setX IN TRANSACTION A
calls setY IN TRANSACTION A
returns to session bean method foo() IN TRANSACTION
A
session bean method foo ends TRANSACTION A COMMITS
(All persistent fields in entity writen as an
INSERT)
client
Perhaps someone will correct me here, but I am pretty
sure about this.
//Nicholas
--- "Poppe, Troy" <[EMAIL PROTECTED]> wrote:
>
> Nicholas,
>
> Thank you for the correction, I skipped these
> possible solutions in my rush to
> get to a solution. My appreciation for bringing
> good solutions to the
> discussion.
>
> A couple of questions.
>
> #1 is difficult and undesirable because I am using
> VOs. Having to break them out,
> and change the create method signatures if I add or
> remove an element is
> undesirable.
>
> #2 Has it's downside as a well, in that I have to
> modify my data model to suit a
> particular technology. Certainly not something I'd
> want to do with a legacy
> system. I have the good fortune of being in the
> midst of designing a new system,
> so this really isn't an issue. It does impact
> others though as they need to be
> aware that their constraints aren't going to be
> checked in the same fashion they
> once were. It also has the undesirable possibility
> of throwing a CreateException
> if the data isn't proper. This begs the question,
> shouldn't the data be checked
> for consistency with the business rules before
> getting to create. The problem
> then is how do you keep the business rules in synch
> with the database
> constraints?
>
> #3 poses a few more questions for me, perhaps you
> can clarify them? Do you know
> if changing the J2EE transactional state has an
> impact on the way in which JBoss
> actually persists the bean. Currently this seems to
> be done as an INSERT/UPDATE
> pair. I'm not getting my head wrapped around how a
> different transactional
> context would change that behavior. If anything I
> could see that the caching
> option *might* have an impact on that. If you could
> clarify, I would greatly
> apprecaite it.
>
> Thanks!
>
> Troy
>
> -----Original Message-----
> From: Nicholas [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 09, 2003 3:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: OT: RE: [Xdoclet-user]
> ejbCreate<METHOD>() and
> ejbPostCreate<METH OD>() code contents
>
>
> I think this falls into J2EE territory again, rather
> than JBoss. To solve this problem, I think you have
> three options:
>
> 1. Make your ejbCreate methods have all not null
> columns in the parameter list. This makes the most
> sense to me as you HAVE to provide them eventually,
> by
> virtue of your data model, and it does not really
> make
> sense to supply the values in a fine[r] grained way
> rather than a coarse grained one.
>
> 2. Used the afformentioned deferred constraints, but
> it depends on the transactional mode of the call. If
> there is already a transaction running and your
> create
> joins that transaction, you're in the clear. If not,
> as soon as the create finishes, your transaction
> will
> commit and the constraints will be applied and if
> you
> have not supplied values for the all the not null
> fields, it will fail.
>
> 3. Along the lines of #2, you might be able to
> ensure
> a transaction is already running when you do the
> create. For example, you could use a UserTransaction
> or modify the commit options of the beans involved.
> In
> this way you can create, postCreate (and perform
> other
> set()s) before the bean even writes out to the
> database. You do not even need a deferable
> constraint
> on the table.
>
> I hope that makes sense.
>
> //Nicholas
>
>
> --- "Poppe, Troy" <[EMAIL PROTECTED]> wrote:
> >
> > Craig,
> >
> > Perhaps this is a bit off topic, but I am curious
> if
> > you know of a way to force
> > JBoss to set 'deferral' of a constraint for a
> > particular transaction? The reason
> > is I would like to avoid building a constraint
> that
> > is "DEFERRABLE, INITIALLY
> > DEFERRED" if I possibly can. Since I'm using CMP,
> I
> > have no way (that I know of)
> > to set the constraint to be deferred.
> >
> > Thanks
> >
> > -----Original Message-----
> > From: Craig Hamilton [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 09, 2003 11:37 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Xdoclet-user] ejbCreate<METHOD>()
> and
> > ejbPostCreate<METHOD>() code contents
> >
> >
> > Troy,
> >
> > This really isn't an issue with JBoss, it is with
> > Oracle. The J2EE spec
> > says that relationships are set in the postCreate
> > method. JBoss sets
> > the primary key attributes with an insert in the
> > ejbCreate, and then the
> > fk fields with an update in postCreate.
> >
> > The problem is that the constraints are being
> > checked immediately, not
> > at commit time. Fortunately there is a fix which
> > works for Oracle.
> > There is a concept of deferrable constraints. You
> > should make foreign
> > keys initially deferred. If you have non-null
> > fields, you will also
> > have to set them up the same.
> >
> > craig
> >
> >
> > --__--__--
> >
> > Message: 12
> > From: "Poppe, Troy" <[EMAIL PROTECTED]>
> > To: "'[EMAIL PROTECTED]'"
> > <[EMAIL PROTECTED]>
> > Date: Wed, 9 Jul 2003 10:28:30 -0400
> > Subject: [Xdoclet-user] ejbCreate<METHOD>() and
> > ejbPostCreate<METHOD>()
> > code contents
> > Reply-To: [EMAIL PROTECTED]
> >
> >
> > I currently have a number of CMP beans that have
> > bi-directional CMRs. I
> > am using
> > the value object pattern as implemented by
> XDoclet.
> > I am running my
> > EJBs on
> > JBoss 3.2.1 against Oracle 8i.
> >
> > In coding my ejbCreate<METHOD>() and
> > ejbPostCreate<METHOD>() methods, I
> > have come
> > across something that I am curious how others have
> > solved this (since it
> > deals at
> > least partly with XDoclet's implementation of
> VOs).
> >
> > It is my understanding that in the ejbCreate
> method
> > you are supposed to
> > get a
> > primary key, set it and return null. In my
> > ejbPostCreate method, I set
> > the
> > contents of the value object. However, when I do
> > this (in JBoss), I get
> > complaints (in ejbCreate) from Oracle about my
> > foreign key:
> >
>
=== message truncated ===
=====
Nicholas Whitehead
Home: (973) 377 9335
Cell: (201) 615 2716
[EMAIL PROTECTED]
Get Your News From The Crowbar: http://crowbar.dnsalias.com:443/crowbar/
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
