Marc, > Simone, > > really, this is not a cache decision, AT ALL. The state > synchronization is > the state synchronization with the DB, it is a different > domain. The cache > should not, does not, will not take state synchronization > decisions with > respect to the database. It is a store with passivation > policies. It will > decide about its passivation policies, i.e. it's memory > management, but > certainly not how to refresh the state from db and to answer > a question you > posed earlier, no, the state sync and the LRU algo are not the same. I see your point, agree. I probably jumped into this class exercise without thinking about it too much, it seemed simpler the other way, but at the end semantically wrong. > Finally (between us) let's try to focus on that one-thread > busy wait problem > (the one that gives the LOCKING WAITING) I took privately > with you yesterday > before we make this piece of code unecessarily complicated ;-) > > In clear let's fix the problems with the current cache before > we touch the > other interceptors yeah? > > sorry to be violent, No problem, why then I nicknamed you "grumpy JBoss" ;) ? > it is just that in *every* interceptor I > have looked at > there is tons of work to be done, sometimes to make it just work. Cheers, Simon _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
