We have seen that each time we access a getter (actually any) method the
bean invokes an ejbLoad method at the start and an ejbStore at the end of
the getter method. Even if none of the persistant data has changed between
the last invokation of a method and the this one. This is of course
extremely inefficent and slow as these methods are invoked at high pace.
Is there a way to optimice this behaviour by means of some properties or
deployment parameters or something else?
We have try'ed BMP but have very bad experience with it (when using Borland
Appserver not with Sun for example). We know of course that the data in the
DB is not used concurrently by any other application not in the same
Application server and neither by any other application.
Thank you for any sugestion on how I could optimize this behaviour.
Tom
Entity beans should always be accessed in the scope of a transaction.
I.e. it is not recommended that you access entity beans from a client
directly (which is what you seem to be doing). Always use a session
facade pattern combined with a value object pattern (see theserverside.com
for details - this topic is beyond the scope of a newsgroup discussion).
See responses inline below:
"Tom Brodbeck" <brod...@freesurf.ch> wrote in message news:3bea6735$1_1@dnews...
> We have created two CMP Entity beans with the JBuilder wizard between which
> there is a 1 .. n relation.
>
> We have seen that each time we access a getter (actually any) method the
> bean invokes an ejbLoad method at the start and an ejbStore at the end of
> the getter method. Even if none of the persistant data has changed between
> the last invokation of a method and the this one. This is of course
> extremely inefficent and slow as these methods are invoked at high pace.
If you call a (remote) method of an entity bean [and the entity bean is _not_
currently in the scope of a transaction], then a transaction is started. This
implies that the entity bean has to synchronize its state from the database
via a ejbLoad() (unless you use Option A or Exclusive access to the DB).
The behavior you are seeing is entirely what the EJB 1.1 mandates. When
a cmp entity bean is invoked, a transaction is started (if there isn't one already),
the ejbLoad() is called ... and when the transaction commits, the ejbStore()
is called. Note that while the ejbStore() is called (it HAS to be - to be compliant
to the spec), it does _not_ imply that an "update" has been sent to the database.
With our AppServer product, the tuned update feature in the CMP (turned
on by default) ensures that if cmp fields were not modified in a transaction,
then an unnecessary database update is skipped (though the ejbStore
method is called). You can verify this yourself by running the container in
debug mode and viewing the sql sent by the container to the database or
even by running a trace on the database provided by your rdbms vendor.
Such a feature is quite unique to our product .. and there are not that many
EJB 1.1 compliant vendors out there who can boast of such a feature built
into their cmp engine (without resorting to a proprietary isModified() or
isDirty() flag)
-krish