Hey
"Lahooti, Hamid" wrote:
> >> It's not that dumb. The container cannot afford to keep every
> >> bean instance that it creates, active. It's easy keeping the
> >> ejb objects, they do not have state.
> >>
> >It's dumb since it's throwing away an instance which will most likely be
> >used
> >pretty soon. It should instead implement some kind of LRU algorithm to
> >keep track of which instances that should be passivated.
> >regards
> /Kalle
>
> That's easier said than done. LRU does not help you when a different
> container updates your bean instance's external representation. Pretty
> soon your cache is out of date!
Passivation of instances does not help with the above problem. The above
is more related to when ejbLoad is called, and which type or row locking
the underlying database is using.
If ejbLoad is called upon transaction start, and pessimistic row locking
was used by the database, then another server would not be able to load
an Entity instance with data from that row until the transaction
commits. If optimistic locking was used then it would be able to load
data, but commits would possibly fail if the row was updated.
Again: passivation has absolutely nothing to do with cache/db
synchronization. That is handled by appropriate calls to
ejbLoad/ejbStore.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
