Floyd,
Your strategy only works if your EJB server reuses the same instance to service
the same EJB object identity for every transaction. Many serves keep entity
instances in a pool and use different instances to service different
transactions for the same EJB object identity. For these servers your strategy
won't work. So your solution is dependent on the EJB server being used and is
not generally applicable.
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition
Published by O'Reilly & Associates
http://www.EjbNow.com
Floyd Marinescu wrote:
> 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".
