Thx. Sounds cool. Is this pattern included on the for-pay docos? Lately I am thinking about buying them since I hear of new behaviour/possibilities included in JBoss. Mainly I'm talking about the new CMP stuff and the JBoss JMX state-of-the-art.
Doesn't matter too much, since I am going to buy them anyways. Dain Sundstrom wrote: > 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 > > > ------------------------------------------------------- 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
