Dean, The code I generated, and the resulting code from XDoclet requires an EJBLocalObject for CMR fields. In addition, my EJB has an ejbCreate() method that takes a single value object. I know I have to set the CMR field in ejbPostCreate(), but how do you get a reference to an EJBLocalObject in ejbPostCreate()? Is there a preferred way of doing this? Should I change the ejbCreate() signature? Should I use a LocalHome to find an object?
Maybe this is the source of my confusion. Thanks. T -----Original Message----- From: Dean C [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 5:32 AM To: [EMAIL PROTECTED] Subject: Re: OT: RE: [Xdoclet-user] ejbCreate<METHOD>() and ejbPostCreate< METH OD>() code contents Bernie, I'm using 3.2.1 and I'm setting a cmr field in the ejbPostCreate method and its working well. And just to clarify, my FK field in the db does not allow null. Having said that, in versions before 3.2.1 I was setting this cmr field directly in the ejbCreate method - whilst this breaks the spec (10.5.2), I didnt see any problems in doing this. Dean ----Original Message Follows---- From: "Meyer-Willner, Bernhard" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: Re: OT: RE: [Xdoclet-user] ejbCreate<METHOD>() and ejbPostCreate< METH OD>() code contents Date: Thu, 10 Jul 2003 08:27:59 +0100 Guys, I'd suggest trying this question on the JBoss mailing list, since this is really more a JBoss issue, rather than a J2EE or XDoclet one. JBoss 3.0.x's CMP engine has this problem that FK columns can't have NOT NULL constraints, because it issues an insert/commit between ejbCreate() and ejbPostCreate(). This is according to the official pay CMP docs and own personal experience. >From what I've heard it hasn't been fixed in 3.2.1, hopefully will be in 4.0 - I don't know. WebLogic, for example, has the option of committing after ejbPostCreate() which would solve this problem. Unfortunately JBoss has not, which made us use JBoss 3.0.5 with CMP entity beans generated thru Middlegen and XDoclet, but w/o CMRs. Rather we're emulating CMR thru the use of ejbSelect()-Statements, because we had to cope with a legacy DB schema which wasn't about to change. Disabling NOT NULL constraints was no option for us, and using INITIALLY DEFERRED on Oracle was no option either, because we needed to have triggers fired at certain events. my 2 euro cents Bernie -----Urspr�ngliche Nachricht----- Von: Nicholas [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 9. Juli 2003 23:28 An: [EMAIL PROTECTED] Betreff: RE: OT: RE: [Xdoclet-user] ejbCreate<METHOD>() and ejbPostCreate< METH OD>() code contents 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 This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ------------------------------------------------------- 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 _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ------------------------------------------------------- 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/bulletproofapps1 _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
