"jason.greene(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote :
| |
| | 1) Store pojos under the session that first passes them to setAttribute.
| |
| | Pros: solves above problems
| |
| | Cons: if webapp stores the same pojo under two different sessions, PC will support
this. But if the first session is removed, the underlying pojo will be removed with it and
if the second session tries to use it they will get an exception.
| |
| |
|
| Are you just referring to making every session a region? This would still have
problems with gravitation, since a shared pojo would either bounce back and forth if we
always force gravitation, or if we don't might not be accessable . Unless of course
you can gaurantee that all sessions associated with a web app are all located on the same
node.
|
Yes, every session is a region. Essentially this would mean saying shared pojos are not
supported, since invalidating a session will remove the pojos out from underneath all the
other sessions. My "Con" above refers to the fact that if people try to share
pojos or do it accidentally, we can't detect that right away -- the call to attach()
with an fqn for the 2nd session will work and create a PojoReference pointing to the
_JBossInternal_ region under the first session.
anonymous wrote :
| IMO if we are going to share pojos and bind them to a special region, then we should
make that region not use buddy replication (if possible).
|
Yes. Logically, if you want to share objects between sessions, the place to put them is in
the ServletContext. There's a JIRA to make that clustered. A clustered ServletContext
cache wouldn't use buddy replication.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146614#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...