[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Scoping of FIELD granularity session pojos
by bstansberry@jboss.com
"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#4146614
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146614
16 years, 4 months
[Design of JCA on JBoss] - Re: JCA login modules moved out of connector module
by anil.saldhana@jboss.com
There is a file called as notxfs-ds.xml in the deployment.
| <?xml version="1.0" encoding="UTF-8"?>
|
| <connection-factories>
| <no-tx-connection-factory>
| <jndi-name>RunAsIdentityFS</jndi-name>
| <rar-name>jca-securedejb.jar#notxfs.rar</rar-name>
| <connection-definition>org.jboss.test.jca.fs.DirContextFactory</connection
| -definition>
| <config-property name="FileSystemRootDir" type="java.lang.String">/tmp/db/
| fs_store</config-property>
| <config-property name="Roles" type="java.lang.String">RunAsIdentityRole,Ru
| nAsRole2</config-property>
| <security-domain>RunAsIdentityFSRealm</security-domain>
| </no-tx-connection-factory>
| </connection-factories>
|
The issue is that the value in "security-domain" element is not getting injected into the BaseConnectionManager2. With the new JCA deployer framework (I did place breakpoints in vain), I am unable to figure out where the gaps are for this data to be injected.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146609#4146609
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146609
16 years, 4 months
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Scoping of FIELD granularity session pojos
by jason.greene@jboss.com
"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.
anonymous wrote :
| 2) Make it configurable via a pojo-scope element in jboss-web.xml, valus are APPLICATION or SESSION, default is session.
|
| Basically, still support the existing behavior. Log a WARN if user specifies ATTRIBUTE with a buddy replication cache.
|
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).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4146607#4146607
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4146607
16 years, 4 months