[JBoss JIRA] Created: (JBAS-5332) Container artifacts should have symmetric lifecycles
by Adrian Brock (JIRA)
Container artifacts should have symmetric lifecycles
----------------------------------------------------
Key: JBAS-5332
URL: http://jira.jboss.com/jira/browse/JBAS-5332
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Reporter: Adrian Brock
Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.3.GA
The container artifacts i.e. [Session|Entity|MessageDriven]Container, interceptors, cache, pool, ProxyBindings
should have symmetric create/start/stop/destroy methods.
e.g. The MessageDrivenContainer does this in destroy
// Destroy container invoker
for (Iterator it = proxyFactories.keySet().iterator(); it.hasNext();)
{
String invokerBinding = (String) it.next();
EJBProxyFactory ci = (EJBProxyFactory) proxyFactories.get(invokerBinding);
ci.destroy();
ci.setContainer(null);
try
{
ObjectName containerName = super.getJmxName();
Hashtable props = containerName.getKeyPropertyList();
props.put("plugin", "invoker");
props.put("binding", invokerBinding);
ObjectName invokerName = new ObjectName(containerName.getDomain(), props);
server.unregisterMBean(invokerName);
}
catch(Throwable ignore)
{
}
}
The setContainer(null) is wrong since it isn't the one that sets the container in create()
that is done by EjbModule in its createService() method
In this case, the fix is to either move the setting of container to MessageDrivenContainer::createService()
or move the nulling of the container to EjbModule::destroyService()
Other artifacts also need checking and fixing with tests writing to validate that each container can
go through a stop/destroy/create/start lifecycle and still function correctly.
--
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
14 years, 6 months
[JBoss JIRA] Created: (JBAS-3770) JBoss/JCA JDBC implementation should allow for Transaction isolation level to be reset on underlying JDBC connection prior to return to pool
by Weston Price (JIRA)
JBoss/JCA JDBC implementation should allow for Transaction isolation level to be reset on underlying JDBC connection prior to return to pool
--------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-3770
URL: http://jira.jboss.com/jira/browse/JBAS-3770
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Weston Price
Assigned To: Weston Price
Priority: Minor
By default, when we return a JDBC connection to the pool we execute the following in the ManagedConnection.cleanup() method:
if (jdbcTransactionIsolation != transactionIsolation)
{
try
{
con.setTransactionIsolation(jdbcTransactionIsolation);
jdbcTransactionIsolation = transactionIsolation;
}
catch (SQLException e)
{
mcf.log.warn("Error resetting transaction isolation ", e);
}
}
In this scenario we don't return the original isolation level on the underlying connection. The spec doesn't prohibit this, and I can't see any reason why we shouldn't do this, or provide a configurable option.
--
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
14 years, 7 months
[JBoss JIRA] Created: (JBAS-4893) JvmRouteValve (UseJK) for non session replication setup
by Takayoshi Kimura (JIRA)
JvmRouteValve (UseJK) for non session replication setup
-------------------------------------------------------
Key: JBAS-4893
URL: http://jira.jboss.com/jira/browse/JBAS-4893
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Takayoshi Kimura
Currently JBoss doesn't install JvmRouteValve for non session
replication setup. However, it's still useful in the following
scenario:
* 1 Apache HTTPD frontend and 2 JBoss AS instances without session replication
* A request goes JBoss node AAA (JSESSIONID=xxx.AAA)
* The node AAA crashed
* The request goes node BBB, lost session, recreate another
* The node AAA recovered
* The request comes back to the node AAA, lost session again
Enabling JvmRouteValve can prevent last failure.
--
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
14 years, 7 months