|Not much help ;-)
|As Rickard proposed, the new lock() method should be implemented in the
|instance cache implementation. Inside this new lock() there is a
|wait() that
|*is* on the cache object, but client can for example insert into the cache.
hummmmm the lock in the cache or not is "repackaging", right now we have a
solution on ctx only that goes to 300 threads (and dies on timeouts, we know
why but can't fix it yet... will do a separate mail, your help is
appreciated there )... let's move on it is a stale discussion, we have a
*very* simple solution and we will commit it right now...
|> |> 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
|
|This is not true, clients can insert into the cache. Other clients that
|calls invoke() have to wait little time since unlock is called just after
|the context.lock logic and before getNext().invoke().
... semantics..
nobody can enter the cache while you hold the lock and so the contention is
large, right now we have contention on the ctx only so much finer grained...
again we will commit right now, with the understanding of the old bug as
well
we are already past it, it works, it's moot, move on... nothing to see :)))
marc
|
|Best Regards,
|
|Simon
|
|
|> |> 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
|> |
|> |
|>
|>
|
|
