|Hey Sebastien,
|
|> Hi,
|>
|> This lock is on the whole cache.
|
|What do you mean exactly ? It seems to me that this lock is not on the
|cache, and it is unlocked as soon as it is not needed.
the lock is on the cache...
|> This means that once it is locked,
|> NOBODY can enter the cache, even with a different context.
|
|This is a statement or a wish ?
|
statement
|> For stateful
|> beans, this solution won't work since activation reads from file,
|
|Do not follow... For stateful this solution degenerates in the
|synchronization statement where the sync object is the instance cache; the
|activation is synchronous with the call to the cache (ie if the object has
|to be activated, the instance int'r waits) ? May you expand ?
this is not correct and in fact for entity it is done the proper way, i.e.
the state sync is in another interceptor.
Acquiring a context and setting it's state are not linked
|
|> for
|> entity there must be a lower contention solution.
|
|It seems to me that the contention is low, since this lock is
|released ASAP.
Still...
ok, we just finished a solution based on the sync(ctx) where we have only
one sync and the cache.get is synced on teh cache.
I *strongly* recommend moving the activation out of that sync (out of the
cache.get) and into a interceptor for stateful beans but that is down the
road, just keep it in mind for now.
The new solution works, and works well (works for 2 threads, 10 threads, 50
threads and almost works for 100 threads *all on the same object*). When I
say *almost* I mean that now we are back on the "timeout" problems that send
the server spinning loco do to a tx that is never cleanly removed
(somewhere) we will track that one down.
marc
|Did you find any problem with it ? Am I missing something ?
|
|Best Regards,
|
|Simon
|
|
