Hi,
Rickard wrote:
>"Lahooti, Hamid" wrote:
> > >* using BMP entity beans with no "setXXX" methods
> > >* before going to the database to retrieve the rows, check if the
> > > entity bean properties are NULL. If they are, load them from the
> > > database, if they are not, assume they have already been loaded and
> > > use them without going to the database.
> >
> > This would work only if you could get the container to
> > keep the bean instance active. In practice, you cannot
> > and the container will passivate the instance as soon as
> > the transaction completes so you cannot really use this
> > method for a singleton cache.
> Which EJB-server does this? I would consider this to be buggy behaviour.
> Activation/passivation are possibly expensive operations, and if my
> EntityBeans were passivated after *each* transaction the performance
> would be incredibly poor.
> What *would* be ok is if it considered the state of the instance to be
> invalidated so that a ejbLoad would be issued upon a new transaction.
> But that's an entirely different thing, and which is what Michaels
> workaround would help control better.
At present, I am implementing the JMX specification. So, I have a registry
(MBeanServer) of ordinary Java Beans (MBeans) which remain in memory for fast read and
write access. I have provided an EJB interface to these objects and delegate
any method calls to the implementation MBean Java objects via an
internal implementation pointer. Whenever I create, activate or load a BMP EJB,
I lookup the registry and retrieve existing, registered objects by primary
key. If they don't already exist then I create them and then register them.
This gives me a cache of in-memory objects with very fast access,
but also provide a remote EJB interface if required. Maybe this concept
of decoupling the EJ Bean implementation and storing it in a cache will help
anybody trying to implement a cache of EJB objects.
The decoupling of EJ Bean and Java Bean is necessary because I found that
IBM Websphere Advanced (WAS) 3.0 when using TX_REQUIRED resulted in immediate
ejbStore() and ejbPassivate() being called after each BMP EJB create transaction.
(This is different behaviour than under WAS 2.0.2. which did not
passivate immediately at the end of each transaction). When
a setter method is called, the ejbActivate() and ejbLoad() methods are called
prior to the setter method being invoked. This is considerable overhead
for accessing objects which are to be used frequently and which should
not have a performance overhead (i.e. 5ms using RMI versus < 1ms for
direct method call access)! After each transaction, the passivated EJBObject
is returned to the pool and then the same EJBObject and EJ Bean instance
are reused for the next EJB create. IBM say that this is correct
behaviour according to the EJB specification and preserves the integrity
of the data if the EJBs are being updated on multiple servers.
BTW, TX_NOTSUPPORTED would be better in my situation, but I was
interested in seeing what the behaviour and BMP EJB overheads would be
using TX_REQUIRED.
Using J2EE with the same BMP EJB's with TX_REQUIRED does not cause immediate
passivation after each transaction. Hence much less store, passivation,
activation and load overhead (not to mention far less SQL overheads).
Also, when a setter method is called in a new transaction, the EJB instance
is already in memory (no activate and load required) so the performance
is better.
So which approach is correct and why? You would think that J2EE should
present the correct BMP EJB behaviour transactional behaviour. But keeping
EJBs in memory after the transaction has finished will lead to data
integrity problems unless they are read-only and unless the developer
takes precautions. Does this mean that for portable BMP EJB development
that we have to cater for the immediate passivation at the end of every
transaction because this is allowed/specified within the EJB specification?
Does this mean that we have to maintain our own dirty flag to decide if an
EJB should be stored during passivation (to avoid an INSERT followed by an
immediate UPDATE of the same, unchanged data values), and that we need
to provide our own mechanism of keeping our own cache of objects
with our own integrity and locking mechanisms? Or should a dirty flag,
central locking mechanism and update notification mechanism be included
in the EJB 2.0 specification so that we do not have to develop these
mechanisms ourself and so that we are not subject to different
vendor implementations?
Geoff
===========================================================================
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".
