[JBoss JIRA] Created: (JBAS-4433) Row-locking enhancement for loading bean outside of a transaction
by Scott Marlow (JIRA)
Row-locking enhancement for loading bean outside of a transaction
-----------------------------------------------------------------
Key: JBAS-4433
URL: http://jira.jboss.com/jira/browse/JBAS-4433
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta1, JBossAS-4.0.4.GA
Reporter: Scott Marlow
Assigned To: Scott Marlow
Fix For: JBossAS-5.0.0.GA, JBossAS-4.2.1.CR1
JBoss recommends that applications should use transactions (see user forum reference). However, there are certain types of applications that use "transaction-type=NotSupported" and load data without a transaction.
If the bean is being loaded without a transaction, treat the operation as if row-locking==false.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 8 months
[JBoss JIRA] Created: (JBAS-4719) Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support
by Scott Marlow (JIRA)
Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-4719
URL: http://jira.jboss.com/jira/browse/JBAS-4719
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Reporter: Scott Marlow
Assigned To: Scott Marlow
Fix For: JBossAS-4.2.2.GA, JBossAS-5.0.0.CR1, JBossAS-4.0.5.SP1 , JBossAS-4.2.3.GA
Part of how JRMPInvokerProxyHA handles fail-over includes removing the reference to the node that left the cluster. However, the dead node is not removed as an equality check is not implemented by certain Invoker implementations.
The relevant code in JRMPInvokerProxyHA is
protected void removeDeadTarget(Object target)
{
if (this.familyClusterInfo != null)
this.familyClusterInfo.removeDeadTarget (target);
}
The code in familyClusterInfo is:
public ArrayList removeDeadTarget(Object target)
{
synchronized (this)
{
ArrayList tmp = (ArrayList) targets.clone();
tmp.remove (target);
this.targets = tmp;
this.isViewMembersInSyncWithViewId = false;
}
return this.targets;
}
Since, we didn't include an equals test in many of the different Invoker implementations, the above "tmp.remove(target)" operation fails. The reason for the failure is due to the "targets" ArrayList changing on every invocation (to reflect the current cluster server membership list), a new "targets" is created (so of course comparing references later will not work.)
A similar problem occurs with the EJB2 load balancers after a cluster membership changes.
I think that these issues will be solved by implementing an equals test in the different invokers that can handle equality testing.
PooledInvokerProxy should implement equals based on ServerAddress.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 8 months
[JBoss JIRA] Created: (JBAOP-485) Override Instrumentor.isBaseClass() in GeneratedAdvisorInstrumentor
by Kabir Khan (JIRA)
Override Instrumentor.isBaseClass() in GeneratedAdvisorInstrumentor
-------------------------------------------------------------------
Key: JBAOP-485
URL: http://jira.jboss.com/jira/browse/JBAOP-485
Project: JBoss AOP
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Kabir Khan
Assigned To: Kabir Khan
Fix For: 2.0.0.CR1
Scenario
1) Load Superclass which matches no bindings, the Superclass CtClass is not marked as modified or frozen
2) Deploy bindings affecting super class
3) Load SubClass, this will fetch in the Superclass (since it is not frozen or modified) and find that it matches bindings
4) IsAdvised on the Superclass CtClass will return true
5) This causes the SubClass to not get the base class basics woven in
==> Errors
Fix:
In 1) if we load a class and it is unmodified, record that in the pool and create GeneratedClassAdvisor.isBaseClass(0 to take this into account when doing the checks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 8 months