Bill Burke wrote:
Bela Ban wrote:
Sacha Labourey wrote:
That's a point. We have to define clear use cases now that we have a better
understanding of usage of HTTP Session clustering in companies. We have to
define different policies for:
- considering when an attribute/session has been modified (no obvious
choice, that must be configurable)
TreeCacheAop is a great solution to this
Are we sure that TreeCacheAOP will be a good solution for HTTP Session and SFSB session replication? When does the size of a full HTTP SEssion or SFSB replication packet become a performance problem? Isn't it enough to avoid replication. I'm saying that it may be enough just to intercept field writes and mark a session as dirty rather than to intercept both field reads and writes and hinder in-VM performance. That optimizing the size of the buffer that is replicated may not have much an effect on performance. Do we have any numbers here?
No, we don't. But just replicating dirty objects is definitely a workable solution as well. Whatever we will end up with here, we'll need some perf measurements to have a comparison to the existing solution.
-- Bela Ban http://www.jgroups.org Cell: (408) 316-4459
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
