The session gets replicated at most once per request, so if you call setAttribute multiple
times in the course of a single request, that doesn't trigger multiple replications.
Replication happens after the request thread exits your application code.
Performance tweaks:
1) In jboss-web.xml use replication-trigger SET instead of the default
SET_AND_NON_PRIMITIVE_GET. Avoids replication after read-only requests. Only do this if
you are sure your code calls setAttribute as part of every request wherein the attribute
object is modified.
2) In jboss-web.xml use replication-granularity ATTRIBUTE instead of the default SESSION.
Only the attributes made dirty during the request are replicated. SESSION replicates the
whole session object.
You could also try replication granularity FIELD, but to use that you'd need to
bytecode enhance the classes you store in the session.
Re: other changes:
NONE instead of REPEATABLE_READ will leave you exposed to providing corrupted state during
state transfer to a new node that joins the cluster. You can try READ_COMMITTED and see
if that gives you an improvment.
REPL_ASYNC is the right choice.
OPTIMISTIC locking will hurt performance of the session repl use case.
Use of a replication queue isn't going to reduce CPU usage. It will just isolate web
request threads from having to block waiting to put replication messages on the wire.
Using "interval" SnapshotMode with a snapshot interval of 10000 in
jbossweb-tomcat55.sar/META-INF/jboss-service.xml may reduce CPU usage if you make multiple
requests that trigger session replication within the 10 seconds. The session will get
replicated just once. Of course this or a replication queue both reduce the
up-to-date-ness of your replicated data.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4148205#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...