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".

Reply via email to