Hi all,
I'm sorry I didn't look at the sources, but if the problem is a
synchronized HashTable.get
did you consider this two very clean options:
A)
java.util.concurrent.ConcurrentHashMap
scales much better than a standard synchronized Hashmap
B)
using a standard HashTable but protect it
with java.util.concurrent.locks.ReadWriteLock instead of synchronized,
if you mostly use "get" instead of "put" you can use a
"readlock" for each get,
readlocks permit many to be taken at same tame, so that no blocking occurs,
but acquiring a write lock blocks all other write and read ops (and has to wait
for all previous to be released).
I hope to be helpful, but must say I don't know the internals of Seam well.
Sanne
2008/6/5 Christian Bauer <christian.bauer(a)gmail.com>:
The option to turn the ManagedEntityIdentityInterceptor off has been
closed
with "we need it for passivation":
http://jira.jboss.com/jira/browse/JBSEAM-468
I'm not sure we need it for a system with a) only javabean components and b)
in-memory/non-persistent http sessions and c) no clustering/replication of
http sessions. Which well, would be really a common scenario. :)
We definitely can't have each thread run into a synchronized (readers block
other readers) HashTable.get() thousands of times during a regular request.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev