When using BMP I can put SQL anywhere, so I can modify my setAddress() method to execute the SQL to update the persistent store directly, no muss, no fuss. Note that this method updates the state of the object in memory and in the database, so it can work with isModified() to avoid the execution of ejbStore() at commit time if nothing else changed. In fact I'd probably include the call to remove the old address there as well if that makes sense. Cheers Jay -----Original Message----- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 9:38 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead to DB corruption > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Georg > Rehfeld > Sent: Monday, June 18, 2001 9:50 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] [ jboss-Bugs-434227 ] ejbStore delay can lead > to DB corruption > > > Hi Gentlemen, > > Jay Walters wrote: > > Seems like an application requiring a CMP Persistence Manager and EJB > > container to execute SQL in a specific order might be asking a > bit much to > > me... > > and Bill Burke replied: > > You'd have the same type of problems with BMP, wouldn't you? > > Sorry G's, I still can't see the point here. With BMP simply > ejbCreate/Store/Remove is called at the appropriate places, > especially ejbStore is called after every business method, isn't > it? If not, would someone PLEASE point me to the code that does > actually deferring the SQL, I just again spent 2 hours in > org.jboss.ejb.** hunting for it. > I'm pretty sure you're wrong here. BMP in jboss does NOT guarantee SQL ordering. BMP uses the same interceptors as CMP(look in standardjboss.xml) and there is no code in these Entity interceptors that differentiate between BMP and CMP. Somebody please correct me if I'm wrong because I'd really like to nail this down. > If I'm right, the BMP guy has all control over execution of SQL > by simply doing the OO operations in some order (having referential > integrity in the back of his head). Besides, is such a thing as > RI useless/hindering in the OO world? I don't think so, even the > pure OO guru respects integrity by i.e. not changing essential > things before he knows for sure, that relatet changes can be done. > (Else he would be no guru and should learn a session from the > relational boys). > Not true, see above. > And, last but not least, in the EJB context, heavily tied to > relational store tier (by practical implementations and at least > 'between the lines' of the EJB specs), it would be a shame to > leave people without referential integrity, by not allowing them > to have it on the store (Database) and not providing it in the > next higher level by declaration (the entiy bean level). > > Again, when the BMP guys have full control, why should EJB Server/ > Container developers want to leave the CMP guys in the wet? > > Note, that I'm not against the push() thing just published on > top the EJB 2 requirement to 'store before find', but I consider > it 'Janus' headed: one side parfumed like a feature, the other one > stinking like a workaround. > I disagree this is klugy. I think the spec is trying to help with "referential integrity" while still giving the Container some room to optimize DB access. > Back to my past suggestion of respecting the ORDER of OO calls: > > A simple, but imperformant, solution would be to execute > storeEntity() after each business method and in create/remove. > > I believe now, that the real flaw is caused by the fact, that > the EJB specs consider every field/attribute of a bean > to be equal in semantics to each other, with the exception of > the Primary Key field(s). But they didn't learn their > lession really from the relational poor mens! They COMPLETELY > ignore the very different semantics of FOREIGN KEYS (place > holders for Associations of all sorts). > > This discussion threads problem never comes up, when changing > simple attributes/fiels, that ain't related to anything, but > the primary key of the bean instance (1:1, normally). > But it shows up, when attributes, that represent associations, > are modified. > > JAWS/JBoss needs to know about the SEMANTICS of fields/columns > and then can come up with performant/'intelligent' handling: > > If deferral to commit time is suggested, then QUEUING up all > store requests related to one TX (including create(), remove() > and store() and possibly find() for DIFFERENT instances/beans) > will help: if ANY store request affects data with FOREIGN KEY / > Association semantics, the queue must be processed physically > to the underlying store, until empty, before executing the call > with association semantics (only as a first attempt, we will > be better in a few days!). > > Thus several changes to simple attributes of the same bean > instance intermixed with creation/removal of other bean > instances would nicely be accumulated to only one store() > operation (and several unrelated create/delete_stores). > > But a change of a FOREIGN KEY / Association field would trigger > the queue processing before doing the change to the assoc field, > resolving this threads sort of problem. Further requests to simple > attributes then again accumulate to the queue. > > Makes sense, doesn't it? Sounds great, but what do we do until somebody takes this up and implements it? Bill _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
