http://www.inprise.com/devsupport/appserver/faq/Availability_Scalability_Per
formance.html
<extract>
1. Parallelized access to Entity Beans. Other EJB containers have to
"serialize" the call to the Entity bean which affects the scalability and
performance. Without a POA like infrastructure your Entity Beans WILL NOT BE
ABLE to service multiple client invocations simultaneously. That is a
serious limitation if you are looking to service millions of concurrent
transactions.
</extract>
http://www.inprise.com/devsupport/appserver/faq/Contract_for_Entity.html
<extract>
The section "Concurrent access from multiple transactions" of the EJB
specification discusses two types of entity access. We implement the model
for multiplexed access. That is, multiple clients can access the entity
simultaneously, without locking at the container level. Note that locking
may occur at the database, but will not occur in the container. Transactions
are used to control access to entity beans. If two different transactions
(e.g., clients) access the same entity, they will in fact see different
instances, each with a separate copy of the state. If the state is modified
in both transactions, then only one of the transactions will be able to
commit, and the other will abort. The concurrency control is done by the
database (more on this in other FAQs). All locking is provided by the
database, via isolation levels specified to the JDBC driver.
Note that the Container supports parallel transactional access to the same
entity. Other "popular" EJB containers serialize access to entities, by
locking. This will obviously have a severe impact on performance.
....
What is the level of support for caching of entity state across
transactions?
A simplistic scheme is that the state of an entity be only cached for the
duration of a transaction. Beans stay in the ready state for the duration of
the current transaction, or until they are removed.
The only optimizations can be in the CMP engine: (Tuned Writes)
avoiding doing updates if the data did not change
only updating the fields that were modified
However we go beyond the basics and you can specify any of the three modes
outlined in the EJB specification.
* Option A: exclusive database access, retains state across transactions
* Option B: avoid passivation/activation across transactions
* Option C: passivate/activate across transactions (the behaviour above)
Note that Option A, in conjunction with field-level modification-detection
in the CMP engine, will allow repeated readonly transaction to run
completely in the container, e.g., without going to the database. This
should be very fast.
Note that this option makes sense only when the entity "owns" the data in
the database. You will have problems if the database is modified externally
(eg by a data base administrator, another app) while the EJB server is
running.
</extract>
No can do with Inprise Application Server. You should just let it do it for
you. Why waste time writing plumbing? Bean managed persistence will not
achieve any kind of satisfactory performance unless used in conjunction with
some good O/R tool and even then there is only so much it can do within the
confines of the bmp contract.
kind regards,
William Louth
> -----Original Message-----
> From: Floyd Marinescu [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, April 15, 2000 5: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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
