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?
Bill
- when session must be replicated (always, time based, etc.)
supported in TreeCache: sync, async (optionally interval-based)
- synchronous or asynchronous
-- ================ Bill Burke Chief Architect JBoss Group LLC. ================
------------------------------------------------------- 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
