This is still very much in the idea stage. This idea came from a Wall Street firm which is using JMS message from an Oracle database to flush the cache. Their system has been in production for a while now.
-dain Ignacio Coloma wrote: > 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 -- 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
