Commit option A and when the row changes in the database a stored procedure notifies the server that the data in cache is no longer valid.
-dain Ignacio Coloma wrote: > What is that "notifications" on A scheme marc is talking about? > > Dan Christopherson wrote: > >> OK, so it's more a matter of allowing multiple bean instances. Once >> that's there, B or C doesn't really matter - the extra overhead >> implied by C is noise compared to the database read (which you need >> either way). >> Of course, anybody that can use option A should. >> >> -danch >> >> Bill Burke wrote: >> >>> Yes, Tom, be more specific. I know you're smarter than that. You're >>> probably talking about the "Instance per Transaction" locking >>> scheme. This >>> works fine with commit-option 'B'. Yes, it is not totally optimized, >>> but is >>> does pool dead instances. >>> >>> Bill >>> >>> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED]]On Behalf Of Dan >>>> Christopherson >>>> Sent: Friday, July 19, 2002 10:08 AM >>>> To: [EMAIL PROTECTED] >>>> Subject: Re: [JBoss-dev] Please support Option B >>>> >>>> >>>> Whahuh? JBoss doesn't support option B? >>>> >>>> Tom M. Yeh wrote: >>>> >>>>> Dear All, >>>>> >>>>> According to the CSIRO report >>>>> >>>> (http://www.cmis.csiro.au/adsat/jboss.htm), JBoss is doing well >>>> with Stateless session beans. It implies reflection, by comparing >>>> to static compiled codes, doesn't affect the performance much, >>>> while it has great architectural advantages such as pluggable >>>> interceptors. >>>> >>>>> However, entity beans is not the case. One of the reason, I >>>>> >>>> think, is this report uses Option B, which JBoss doesn't support >>>> (and uses Option C instead). In other words, all beans are >>>> trashed after a transaction is completed. It then introduces a >>>> lot of overhead since every transaction has to reload all beans >>>> involved from database (and you know accessing database kills the >>>> performance). >>>> >>>>> After examining the codes and a few talks with Bill, I don't >>>>> >>>> think I am capable to modify the codes to support Option B. Any >>>> volunteer is willing to do that? >>>> >>>>> Thanks and Regards, >>>>> Tom >>>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This sf.net email is sponsored by:ThinkGeek >>>> Welcome to geek heaven. >>>> http://thinkgeek.com/sf >>>> _______________________________________________ >>>> Jboss-development mailing list >>>> [EMAIL PROTECTED] >>>> https://lists.sourceforge.net/lists/listinfo/jboss-development >>>> >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by:ThinkGeek >>> Welcome to geek heaven. >>> http://thinkgeek.com/sf >>> _______________________________________________ >>> Jboss-development mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >> >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> >> > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- xxxxxxxxxxxxxxxxxxxxxxxx Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
