Hi,
A couple of weeks ago I posted a question on the BEA EJB interest group
and I got responses that point to a limitation in the EJB specs. As a
result, I would like to post the same question in this group to see if
indeed there are limitations, and if what I am looking for is achievable
now or in the future using EJB. Last but not least, I would like people
to take a fresh look at the issues and see if I have a valid point in my
quest.
Most real life applications are not of the "adjust" type as the classical
banking application, in which I see the balance in my checking account on
my computer terminal at home, type in the amount to transfer from checking
to savings, and click the button to execute the operation. In case my
wife has paid for a big purchase using her ATM card just after I
downloaded the data but before I hit the transfer button, my transaction
could be aborted with the appropriate error message and it really does
not matter that I did not see the change "in real time."
In applications of type "set," users or even programs may set the values of
objects in the database concurrently; without a "real time" notification of
the changes, what one user does may overwrite what another user has just
saved, and the program may not be able to tell that something has been lost.
Of course, even with such "real time" notifications, the client software
needs to detect and handle situations in which someone else's changes get
pushed to the user's terminal while the user is editing the modified field.
In order to have "real time" notifications, the EB should store pointers
(a set) to every client that is using the bean. Each time a bean is
accessed by a client, the remote pointer is checked against the stored set
and if the pointer does not exist already, it is added to the set. Since it
is difficult to ask the client to specify when it no longer needs a bean,
purging the set of no longer valid pointers could be done when a bean is
pushing changes back to all clients. Then, the bean can detect that some
clients are no longer active and remove the corresponding pointers from
the set.
This strategy assumes that there is at most one bean object active in the
EJB server at any time. This should also be true of a "clustered" server.
Were this condition not true, the set of pointers to clients would be
distributed and any bean object would presumably store part of the set.
Therefore, the first question would be: should the EJB spec mandate that
there was a single entity bean instance in memory at any one time,
even in a "clustered" environment?
The second question relates to passivation. At any one time there are
a limited number of bean instances in memory. When new instances are
needed to satisfy the request of a client, some of the instances are
passivated and the bean objects reused for other beans. Passivation
involves saving the appropriate records to the database. However, in
my case, the remote pointers cannot be saved to the database but must
be somehow preserved. I could serialize and deserialize the objects
myself upon passivation / activation, but it would be nice if the
bean container did it for me. Particular non-db variables in the
EJB could be recomputed upon activation, but definitely the set of
clients accessing the beans cannot. The pointers must be saved and
restored. Thus the second question is: could the EJB standard require
the EJB container to serialize non-db variables upon passivation and
de-serialize them upon activation?
Vladimir
===========================================================================
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".
