|I would have written a simple TimerTask in a LRU cache policy, as I've done
|for the stateful bean removal.

and I would have removed it

|The issues (entity beans invalidation and stateful beans removal) are very
|similar, aren't they ?

no, like not at all.

One deals with memory of the store/cache (stateful) the other one with
policies of refreshing (synchronization of entities)

|I saw you use java.util.TimerTask.
|I reimplemented them because in the early days we wanted to be compatible
|with jdk1.2.2, and these classes were added only in JDK 1.3. I
|don't know if
|this constraint is still there (running the server in a 1.2.2 JVM) but...

yes it is still a requirement, good point.  Vinay please use this class from
Simone.

|> 4. The interceptor does NOT reload the entity. It just
|> invalidates the cache. The entity reload is managed by the
|> EntitySynchronizationInterceptor.
|
|YES

Well don't get all excited, that is what teh ESI does :)

|> Does anyone want to go thru this and get back to me?
|
|As I've pointed out I would have written it with a org.jboss.util.TimerTask
|in a LRUEntityContextCachePolicy subclass.
|In there I would have locked the cache, walked all the cached context and
|call setValid(false) on them, more or less like in the
|LRUStatefulContextCachePolicy.
|What do you think ?

that both of you are picking strawberries like we say in france (ask Farid
for a translation vinay ;-)

marc

PS: I already sent the 6 lines needed to make this work, have a good day,
peace love, and simple code.

|
|Cheers,
|
|Simon
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to