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#4148205 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4148205 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
