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. 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. In my opinion you are making an application design decision that involves tradeoffs. You are utilizing a feature provided by your particular server vendor to allow your code to work given a particular application design. You are potentially trading off portability and definitely trading off performance. That doesn't mean it is a bad decision, just that the decision has consequences.
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
