Francis,
<vendor>
I was curious about your statement:
you will have a great delay due to the locking of the EB
What locking are you talking about? Some containers implement
pessimistic locking (for example, WebLogic) in which case locking
can be a significant performance issue. However, some containers
implement optimistic locking (for example, IAS) in which case there
is no such locking by the container. Of course, you still need to
look at the locking model of the DBMS, but again you have choices
here, and using a database which supports optimistic locking would
avoid such performance problems.
Or did I miss the point?
</vendor>
-jkw
Francis Pouatcha wrote:
>
> Hi Ben,
>
> Entity beans (EB) are not appropriate for the purpose you depicted
> bellow. Because of the intensive concurent acces to the Bean, you will
> have a great delay due to the locking of the EB. It is beter to
> implement it like a read only like cache. Also loading and unloading EB
> isn't deterministic, these operations depend on how the server is
> implemented (an EB wich is realy hited will even never be unlaoded).
> Setting timeout on entity bean isn't specified. If you do it, your bean
> won't be portable.
> If your DB get updated from time to time, I see two portable sollutions
> for updating the cache:
> -UpdaterBean (Entity) using a timer service (i.e. over JMS) that triger
> the bean to update the cache every 30 min.
> - Simply use System.currentTimeMillisec() from inner the cache to
> measure the age of your cache and update it when needed, but this will
> only be done when a request is sent to the bean since the bean can't
> triger itself.
>
> /Francis
===========================================================================
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".
