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: > > javax.ejb.CreateException: Could not create > entity:java.sql.SQLException: > ORA-01400: cannot insert NULL into > ("HR"."ASSIGNEDPOSITIONSTATE"."ASSIGNEDPOSITIONID") > > Now, the contents of my foreign key relationships > are in the value > object, and > will be set in ejbPostCreate. > > So there are a couple questions. > > 1. Should I be setting the values of my NOT NULL > fields in ejbCreate()? > 2. Is there some way that I can force JBoss 3.2.1 > to hold it's horses, > and set > the rest of the values in ejbPostCreate()? > > Thanks in advance. > > Troy > > > > > ------------------------------------------------------- > 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 > > > > ------------------------------------------------------- > 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 ===== 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 ------------------------------------------------------- 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
