He's not removing the modified bean: he's removing a bean that the modified bean used to refer to. The issue is that the remove causes a data change immediately, while the table behind the modified bean still has the foreign key for the row that's being removed. This violates referential integrity - boom! I thought of suggesting that he put the 'setRecord' method into a RequiresNew transaction, but that would break his transactional semantics (and might deadlock him). I suppose he could just break the remove into a separate transaction, but logically, the code he has is exactly what makes sense as a single transaction. Jay Walters wrote: > He wants the update SQL to execute before the remove SQL? The commit isn't > the issue, it's the order of operations. > > What does the spec say about when remove() needs to execute the SQL? > > My question would be, if the bean has been removed should the persistence > manager still be trying to update it? I can understand that one might want > to somehow consider side effects, such as a database trigger so maybe one > can't optimize out the update. > > Cheers > > -----Original Message----- > From: Scott M Stark [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 15, 2001 12:38 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem > > > Why is this a serious problem? The weblogic docs for the flag you mention > indicate the commit is still not done until the end of the transaction and > that you would only notice this if your db allows for uncommitted reads. > > <snip> > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development >
Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
