Hi, there are some more problems with caching EB state between transactions: - you have to consider a tx abort. The container does not inform an EB that a tx was aborted. This may cause an inconsistency between the cached EB state and the DBMS. - you have to ensure that only the one container process accesses the DBMS. Clustering will not work. If you plan to use clustering, even in the case of CMP the dbIsShared flag (which is weblogic specific) has to set to false. In our project, we solved the problems (at least we hope so...) by reading a db timestamp in the ejbLoad method. If the timestamp value is identical to the cached timestamp, all is fine. Otherwise an abort happened or another process wrote new data, so ejbLoad performs a full load of the EB state. This works fine, but reading a timestamp is expensive too :-( A faster solution might be to use the naming service for timestamp administration. Marc. craber%GEMSTONE.COM@Internet 17.04.2000 16:54 An: EJB-INTEREST%JAVA.SUN.COM@Internet Kopie: (Blindkopie: Marc Volz/TLC/DE) Thema: Re: An easy way to create an in-memory-database entity beans Floyd, Nice idea but, Your solution assumes that the server kept around the instance with the same PK loaded in a previous transaction. This may work in some servers, but there is no way to guarantee you'll get this behavior across implementations (it's not prescribed in the spec). Sorry. -Chris. > -----Original Message----- > From: Floyd Marinescu [SMTP:[EMAIL PROTECTED]] > Sent: Saturday, April 15, 2000 12:31 AM > To: [EMAIL PROTECTED] > Subject: An easy way to create an in-memory-database entity beans > > Hi everyone, > > Most appservers re-load your entity bean before each transaction call, > to ensure consistency with the database. However, if you can ensure that > the > database won't be changed by anyone except your app. server, these > numerous > and expensive load calls should be avoided. A bean should only be loaded > when it is activated (associated with a particular instance). > > In weblogic, you can set an isDBShared deployment flag to be false, > and weblogic will only call ejbLoad() once, just after activation. > > The innovation I wanted to get some from you guys on,is how to mimic > this isDBShared behaviour in app.servers that don't support it. > > The solution seems simple, just make your own isDBShared flag, set it > to false, and in your entity beans, have another flag called isLoaded. > The isLoaded flag should be set to false upon passivation, and set to > true in ejbLoad(), after loading is complete. > > Now when a transaction is about to happen, your app.server will call > ejbLoad. At this point, before loading anything, have the following code > block: > > if ( !isDBShared ) > if ( isLoaded ) > return > > Now after loading, just set isLoaded to true, and your done! Your bean > will not be re-loaded until it has been associated with a new instance > (after passivation-activation). > > The isLoaded flag, together with the isModified flag should give you > an in-memory database, and now OO zealots like me will no longer have to > write JDBC code in "getter" methods cause its "supposedly faster than > going > through the entity bean layer! :) > > Floyd > > ========================================================================= = > = > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
