Here's an example to further illustrate why delayed ejbStore() is
problematic.
What about a situation where you keep a 'bucket' in a table to improve the
performance of your application. For example, you keep a
"current_account_balance" in your User table rather than doing a
SUM(transaction_amount) on your Transactions table each time you need an
account balance.
In a Session Bean, I should be allowed to do something like the following
(very roughly pseudocoded):
TransactionBean t = transHome.findByPK(xxx);
t.setTransactionAmount(765.99);
DataSource ds = (DataSource)lookup("MyDS");
Connection con = ds.getConnection();
Statement stat = con.createStatement();
ResultSet rs = stat.executeQuery("SELECT SUM(transaction_amount) AS total
FROM Transactions WHERE user_id = 444");
UserBean u = userHome.findByPK(444);
u.setCurrentAccountBalance(rs.next().getFloat("total"));
Something like that ... In the above case (i've tried it in several areas in
my app), the SELECT() statement is still reading the old data because the
Container hasn't written the changes out ... Of course, I MUST ensure that
this happens in a transaction so that in case there is a problem, I don't
end up with unsynchronized data ..
(I use this example to point out that it's not just that ejbRemove happens
immediately ... making ejbRemove delay as well would not fix the situation i
just described)
-Dave
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of danch
> (Dan Christopherson)
> Sent: Friday, June 15, 2001 1:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> 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
> >
>
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
