Hi John,
I don't think there is a 1-to-1 relationship between EJBOBjects and bean
instances; this issue is vendor-specific, but I'm sure most server pool and
reuse EJBObjects just like they do bean instances. The reason why
EJBObjects can be pooled and recycled is because they don't contain client
state info; EJBContext does. Hence the server can swap Contexts between
EJBObject and bean pools, and they do a good job of managing the pool sizes.
I don't think you really have to worry about EJBObject instances on the
server side; our architecture uses fine-grained entity beans and I have
never run into OutOfMemory or OutOfEJBObject exceptions! (WL 5.1, 6.0).
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
To: [EMAIL PROTECTED]
Sent: 2/28/01 7:31 PM
Subject: EJBObject life cycle for entity beans
Hi All,
I'm doing some work on a container at the moment
and have a question that I hope someone might be
able to help me with. The issue is with regards
to the life cycle of the EJBObject instance for
entity beans.
With session beans, when a client has finished,
it can do a remove() on the remote object and
the container can remove the EJBObject instance
associated with the session bean instance and
pool the bean. Similarly, if the session times
out then the container could remove the EJBObject
instance and pool the bean instance.
However, for entity beans, the client will not
call remove() on the remote object unless it
wants to remove the data from the database.
Because of that, the container has no easy way
of knowing that the client has finished with
the bean. For a container architecture with a
1-1 relationship between EJBObject instances
and entity bean instances, the number of
EJBObjects instances could just keep growing
and become too big and my question is how can
I decide to delete them?
Initially I thought that maybe I could delete
the EJBObject instance once a client transaction
has finished but there's no way of knowing that
the client isn't going to execute another
transaction a short while later, and I'm not sure
if client communication always has to be within a
transaction. One option might be to let the
EJBObject timeout after a certain period of
inactivity but clients are also able to save an
EJBObject handle for use later on so there would
be problems there - unless the timeout was ignored
by EJBObject instances who'd been getHandle()'ed
by a client. Maybe another option would be to let
them timeout and have an EJBObjectFactory create
instances on the fly as required? Or maybe my
1-1 relationship between EJBObject instances and
entity bean instances should be a changed to a
singleton EJBObject instance delegating to
multiple entity bean instances, although this
seems like it might be a bit of a bottleneck.
Any ideas or comments appreciated.
Cheers,
John.
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
========================================================================
===
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".
