j2ee version

[aguizar]

The timer service was introduced in EJB 2.1, part of J2EE 1.4. However, the current deployment descriptor follows the DTD for version 2.0.

Is there any reason to describe the enterprise beans with the older version, even if the timer bean will not deploy there? The command receiver and the command executor beans can probably be made to work under EJB 2.0. Is our intent to make these beans deployable separately? Do we really want to target J2EE 1.3?

[tom.baeyens]

Well spotted !

This is unintentional. We target only J2EE 1.4 and higher.

[mvaldes]

Definitely agree, 1.3 is out of scope !

BTW, are there any difference concerning the timer service between 1.4 and latest 1.5 ?

Would be great to know the jboss position on 1.5 support ? seems like your first target is 1.4 ?

thanks,
Miguel Valdes

[tom.baeyens]

first target is ejb 2.1 and related j2ee 1.4 versions.

cause all ejb3 containers also support ejb2.

so developing those session implementations in terms of ejb2 will make sure we can run on the most possible platforms.

[koen.aers]

Last week while I was at a customer for some consulting they mentioned problems with the 'unclusterability' of the ejb timers on some appservers. Is that issue being addressed in the PVM?

Regards,
Koen

[tom.baeyens]

i'm not aware of this issue.

can you elaborate or let the customer elaborate.

[koen.aers]

Apparently EJB timers are not necessarily clusterable according to the specification. On some appservers (e.g. JBoss AS, Weblogic) the timer would be specific to the node where it is created. If this node goes down, the timer will not execute. On other appservers (e.g. Websphere) the timer is replicated to the other nodes of the cluster so that when one of the nodes goes down the timer still is triggered.
This is the description of the problem by the customer but maybe it is a simple user problem. I didn't know enough about the specification and I certainly don't know enough about the particular appservers to be sure of this statement. Maybe someone else in this forum does.

Regards,
Koen

[tom.baeyens]

... that means that our own timer impl is better then the jboss one ?!

cool! :-)

[koen.aers]

Don't cheer too quickly. They mentioned problems with that one as well (but again, I didn't verify).

The problem was that the name of the timer includes somehow the name and/or IP address of the node on which it is created. So it didn't work in a clustered way neither. But they didn't show me a hard proof on this.

Regards,
Koen

[aguizar]

Clustering/failover is an aspect left to the EJB container. No component in the EJB spec is required to be clusterable. That is an area where vendors are expected to compete.

The spec does require the container to recover timers upon restart. From EJB 2.1 section 22.4.2:

Timers are persistent objects. In the event of a container crash, any single-event timers that have expired during the intervening time before container restart must cause the ejbTimeout method to be invoked upon restart.

Knowing that support for timer clustering is not uniform across app servers is great input. I wonder what would be a better investment: to work around it in the product or contribute to the EJB timer implementation in JBoss AS. In any case, both can wait until there is enough demand for the feature.

[koen.aers]

Knowing that support for timer clustering is not uniform across app servers is great input. I wonder what would be a better investment: to work around it in the product or contribute to the EJB timer implementation in JBoss AS.

I think for this particular customer the first way would probably be a better solution because they are deploying on multiple appservers. But for the JBoss AS integration, the second solution is of course better.

Regards,
Koen