JBAS-993 broke the dependency contract

[starksm64]

The changes associated with the http://jira.jboss.com/jira/browse/JBAS-993 seem to have broken the dependency contract. All entity containers are started by the EjbModule start, but entity containers are not fully initialized until a subsequent iteration that calls startPmAndInterceptors:

 protected void startService() throws Exception
 {
// Start all ejb containers
 ListIterator iter = containerOrdering.listIterator();
 ArrayList entityList = new ArrayList();
 while( iter.hasNext() )
 {
 Container con = (Container) iter.next();
 log.debug("startService, starting container: " + con.getBeanMetaData().getEjbName());
 serviceController.start(con.getJmxName());
 if(con.getBeanMetaData().isEntity())
 {
 entityList.add(con);
 }
 }

// A second loop to fully start the entity containers.
 if(!entityList.isEmpty())
 {
 for(int i = 0; i < entityList.size(); ++i)
 {
 EntityContainer con = (EntityContainer)entityList.get(i);
 con.startPmAndInterceptors();
 }
 }
 }

The first loop should not be starting the entity containers as this breaks the dependency contract. This is showing up in a support case where porting an app to 4.0.4.GA is showing "createBeanClassInstanceCommand == null" errors when an entity is accessed, but the interceptors and pm have not been started.

[aloubyansky]

Jira issue for this bug: http://jira.jboss.com/jira/browse/JBAS-3341

[aloubyansky]

Actually, I don't think the changes committed as a fix for JBAS-993 introduced the bug. Before the changes, the initialization of the commands of every JDBCStoreManager in the EjbMOdule was triggered by the startService call on the last EntityContainer in the EjbModule. So, by that time all the other EntityContainers in the EjbModule have successfully passed the startService phase.

The right service to depend on in this case would be the EjbModule, not the EntityContainer.

[aloubyansky]

But if I move startPmAndInterceptors() to the EntityContainer.startService() the testcase passes...

[aloubyansky]

Actually that's not surprising since the testcase has only one EJB.

[starksm64]

Ok, I see. Where was the logic for the last EntityContainer startService call in the EjbModule? I don't see it looking at the EjbModule, EntityContainer of 4.0.3SP1.

[aloubyansky]

I am checking out 4.0.3.SP1 now. But I guess it's the same as in the current EjbModule, i.e. in the EjbModule.startService.

I was thinking about moving persistenceManager.start() to EntityContainer.createService() right after persistenceManager.create(). At this point all plugins are created and set, not started though.
The start() of the persistenceManager will use the DataSource and possibly the TransactionManager. Is this acceptable?

[aloubyansky]

BTW, what is the correct tag name for 4.0.3.SP1? JBoss_4_0_3_SP1 doesn't seem to be correct. Is it Branch_4_0_3_SP1?
Then I can see JBoss_4_0_3_SP1_CP_2006_06 and then patches.

[starksm64]

JBoss_4_0_3_SP1 is the correct cvs tag for the 4.0.3.SP1 release. I'm using it to browser diffs between versions.

[aloubyansky]

Right, I confused it with Branch_4_0_3_SP1 again.

Containers are started in the same way, i.e. in the EjbModule.startService by invoking serviceController.start(con.getJmxName()).

[starksm64]

I was thinking about moving persistenceManager.start() to EntityContainer.createService() right after persistenceManager.create(). At this point all plugins are created and set, not started though.
The start() of the persistenceManager will use the DataSource and possibly the TransactionManager. Is this acceptable?

It depends on how fine grained we want to be with dependencies. The ejb-deployer should have a dependency on the TM (and it does), but the datasouce can be deployment specific so we would have to rely on startup semantics other than dependencies for this to work. The PM should have its datasource injected via a dependency such that its not really started until the datasource is available.

Back to the original JBAS-993, can't there just be better tracking of the ejbs causing the errors rather than having to start the PM differently?

[aloubyansky]

The whole issue was about a message like this: "failed to start EJB1: query in EJB2 could not be compiled". The exception is thrown from the last entity (as a service) in the module. So the causing exception is wrapped.

BTW, moving pm.start() to EntityContainer.createService() won't fix the exception message but only the dependency issue.

[aloubyansky]

"Scott" wrote:
but the datasouce can be deployment specific so we would have to rely on startup semantics other than dependencies for this to work.

I think, a datasource should always be deployed before EJBs. EJBs may need a datasource to start but datasources don't need EJBs.

"Scott" wrote:
The PM should have its datasource injected via a dependency such that its not really started until the datasource is available.

There are cyclic dependencies: EntityContainer cannot start until its PM is started while the PM is started from the EntityContainer.startService().
PM.start() should be called before EntityContainer.startService().

Maybe, EjbModule.createService() after the loop that creates all the containers, there should be another one that starts PMs.

[aloubyansky]

So, is it ok to assume that after EntityContainer.createService() returns, the DataSource is availble and can be used?

[starksm64]

It does not match our service life cycle contract in that a service is generally not usable until its started and the dependent service has its start called.