> Sachin Aggarwal wrote: > > >> I think this is a pretty simple issue and when I brought it up with our ejb > >> server vendor( weblogic) - I was told they were fixing it. Now they have a > >> delay_update property that can be set to false and then the database will be > >> in synch with the memory all the time . > >> I don't like the solution of hitting the database for every settor and was > >> hoping to find a better solution. > > Chip Wilson replied: > > >There can be no other solution, since the entity beans may use bean-managed > >persistence. To provide the behavior requested of the finder method, the > >container will have to call ejbStore after any entity bean method is invoked, > >possibly many times on the same bean instance within the same transaction. This > >will end up executing multiple SQL update statements on the same records within > >the same database transaction. > Dirk Willecke wrote: > I don't think the container has to keep the database with the memory ALL the time. >Only the finder methods look up the database directly bypassing all changes in >memory. It is sufficient to synchronize with the database before executing the >SQL-query in a finder method. There is no need to do this after every setter method. >If you're using a finder method in the "proper way" with "good" application design, >this would probably often be at the beginning of a transaction. > In this case there would be no "dirty" entity beans envolved in the current > transaction and there would be only a minimal performance loss. > For any optimization, there is an underlying assumption. The assumption here is that database selects occur only in finder methods. I can think of three other scenarios in which selects occur within an EJB transaction: 1) In ejbLoad. I have always favored designing the component model so that the object graphs of entity beans are mutually disjoint. Others have argued that this restriction is unnecessary. If the data associated with an entity bean instance is not disjoint from the data associated with every other entity bean instance, then any call to ejbLoad from within a transaction could select data that has been updated as part of that transaction. Since the container controls calls to ejbLoad, the same optimization could be performed. Now it would be "Call ejbStore on all entity beans associated with a transaction before calling any finder method or ejbLoad method". 2) Lazy initialization. For entity beans with bean managed persistence, some argue that the bean may defer loading some of its state until it is required; i.e. until someone asks for it. Since this could happen as the result of calling any transactional method on a bean with bean managed persistence, we now have "Call ejbStore on all entity beans associated with a transaction before calling any finder method or ejbLoad method, or before calling a transactional method on an entity bean using bean managed persistence". 3) Session beans. It has been argued that session beans should sometimes access the database directly using the current transaction context. Any transactional method on a session bean could potentially do this, making our optimization "Call ejbStore on all entity beans associated with a transaction before calling any finder method or ejbLoad method, or before calling a transactional method on an entity using bean managed persistence or before calling a transactional method on a session bean". Are there other scenarios?
begin:vcard n:Wilson;Chip tel;fax:(214) 358-0353 tel;work:(214) 642-4559 x-mozilla-html:TRUE url:http://www.axyssolutions.com/ org:Axys Solutions adr:;;;Dallas;TX;; version:2.1 email;internet:[EMAIL PROTECTED] title:Application Architect note:Sun Certified Java Architect x-mozilla-cpt:;-25088 fn:Chip Wilson end:vcard
