John,
I suggest that you embed the primary key into your client object references
(for a CORBA-based server, embed the primary key within the object_key part
of the IIOP profile). You might want to add to that a per-client unique id
to allow multiple clients to have distinct references to the 'same' entity
at the same time.
Then you can allow your EJBObject's to timeout when they are not in use by
a running transaction, and reconstruct them from the object_key that is
present in the request header for the next client request that attempts
to use them. Your table of aactive EJBObjects within the server can be keyed
by the per-client unique id.
Anyway, hopefully these are helpful suggestions.
Also, if you haven't already done so check out the CORBA Portable Object Adapter
architecture.
john morrow wrote:
>
> 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".
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
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".
