I think in this example, though, you're mixing paradigms too much. If
you want to write SQL in session beans, go ahead. If you want to use
entity beans as an object layer over the database, do that. You will
have to be very carefull in mixing them this way.
<purist-hat>EJBs are intended to be an Java/OO technology - I'd expect
to do the summation in the Java space, not the SQL one.</purist-hat>
Will that perform well enough? It depends on the sizes of your datasets
and how you define 'well enough'.
I think this is another case of the various trade-offs in the EJB spec -
Its a distributed object component technology, and dismays the RDB folks
sometimes, but a lot of it seems aimed so squarly at relational storage
on the backend that it bothers the OO purists at other times.
Imagine if the default behavior were for the ejb container to perform
store after every method call - people would flog the database to death
calling individual getters and setters! Adding an option to perform
ejbStore inline would need to have a fairly fine degree of granularity -
per method, I think.
David Esposito wrote:
> 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
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.
