I agree completely with you ... I knew when I wrote the original message
that there would be some strong opinions from both sides of the aisle... I'm
obviously shaded to the RDB side of the aisle mostly because I realize that
there are major performance benefits to letting the database do the work ...
For large applications where a particular entity may have millions of
records, it's impractical to assert that keeping all of the business logic
in the Java space is the best choice.
There are a few ways to handle this and each has its pros and cons. The
unfortunate part of this not being addressed in the bean spec is that each
Container provider will implement their own solution to this problem ... I'm
not a super big fan of Weblogic's solution, but it's better than nothing ...
A) Implement a hack to the Remote interface so that if there is a load() or
store() method in the remote interface, this will trigger the appropriate
ejbLoad (loadEntity) or ejbStore (storeEntity) actions ... (similar to the
way that remove() triggers the ejbRemove (removeEntity) method)
Pros: This will give developers the highest level of control over how the
bean is synchronized with persistent storage ... We will also maintain a
level of caching at the bean layer which would be better than the weblogic
solution .. (i.e. When there isn't a need to synchronize with the DB, we can
use the current Container behavior of keeping the data cached until commit)
Cons: It means that our application (client) code has to be JBOSS specific
...
B) Implement a change to the deployment descriptor similar to Weblogic's
Pros: This keeps the details out of the application (client) and in the
hands of the Container. If this is addressed in a future bean spec or there
is some consensus on how to deal with this in the future, less code changes
and regression testing will be neccessary
Cons: This will lead to a performance drop for the 90% of the cases where I
use my particular bean and this problem DOESN'T manifest itself ... Our
general policy is to only have one getXX() method and one setXX() method for
a bean that reads and writes all of the fields in one shot (to minimize RMI
overhead) but does increase the overall network load ... so in our case,
this wouldn't really be a major performance issue because most of the beans
only have one "setter" ...
C) Do nothing
Pros: Zero development time ... Keeps the OO purists happy
Cons: It will make us rethink our use of JBOSS and EJBs, and either move to
Weblogic, or abandon EJBs entirely ...
Personally, I would be satisfied with solution A or B ... ;) ... Solution B
is somewhat more desireable for the purists in the room because it leaves
the details of persistence out of the application developer's hands (well,
not completely, they would still have to add the flag to th deployment
descriptor, but they wouldn't have to worry about "should i force a store()
after these set operations?") ... Solution A is somewhat problematic because
there are some backwards compatibility issues ...
Anyway ... I appreciate everyone's input to this issue as it is a pretty
significant roadblock for our project... We have been very impressed with
the quality of JBOSS and we have made very positive comments to our fellow
Weblogicians about the JBOSS ...
-Dave
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of danch
> (Dan Christopherson)
> Sent: Friday, June 15, 2001 2:39 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] ejbStore() delay seems to be a serious problem
>
>
> 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
>
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
