> 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!
>
>Yes, if you have multiple JVMs running that's the case.
it doesn't have to be another JVM. Just a legacy application
(there are a lot of them still around) that updates the entity bean table.
>But that doesn't mean every container should throw away each instance as
>soon as the transaction is completed.
I agree but the products that I have used do exactly that and I am
trying to find justification as to why they do it.
>That means that either the same database should be used by all
>running instances (not copies) and that the containers should load any
>data needed if it suspects that it is inconsistent. If you want to
load->balance on every call, then you would passivate all the time, but in
my >opinion that's a bad way to do load-balancing (and doesn't fit entity
>beans, session beans would seem more adequate).
It isn't about load balancing. It is about the container offering
cached active bean instance state without guaranteeing that the
state is a true representation of what is currently in the database
(and committed). If your instance is kept active beyond transactions,
when does instance state get refreshed from the database.
Regards,
Hamid
===========================================================================
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".