Scott,

Developing code understanding for TimerServices.
Also facing some build issues after checking out
jboss-4.0.x
Putting down my notes, please let me know if i am on
the right path.

Problem Statement:
For all Stateless beans (MDB, Entity, Session),
support persistence across server shutdown/ startup
(or) restart. Persistence across crashes is already
provided. If timer expires during the shutdown period,
execute it once on system startup.

Code Understanding:

All interfaces defined under jboss/j2ee/src
TimerImpl code is at:
jboss/server/src/main/org/jboss/ejb/txtimer

Timer method Services start with two transaction
modes:
NotSupported/ RequiredNew

TimerImpl: Uses java.util.Timer and tracks tx state
TimerServiceImpl: Binds the Timer with the
TimerInvokerObject and provides impl. of createTimer
calls
TimerInvokerObjectImpl: implements the ejbTimeout
Persistence policies and files are also present.

Questions:
1. What is the diff. between EJBTimerService and
TimerService. Is it that EJBTimerService supports
RequiredNew and TimerService is for NotSupported?

2. Build is not going thru on Win XP for jboss-4.0.4,
however succeeds for jboss-head. Using TortoiseCVS and
anon. for checkout. Build error as follows:

[javac] Compiling 24 source files to
C:\JBOSS-~1\jboss-4.0\test\output\class
es
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestCase.java:14
:
cannot
resolve symbol
symbol : class MBeanServerConnection
location: package management
import javax.management.MBeanServerConnection;
^
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestServices.jav
a:13:
ca
nnot resolve symbol
symbol : class MBeanServerConnection
location: package management
import javax.management.MBeanServerConnection;
^
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestServices.jav
a:52:
ca
nnot resolve symbol
symbol : class MBeanServerConnection
location: class org.jboss.test.JBossTestServices
protected MBeanServerConnection server;
^
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestServices.jav
a:111:
c
annot resolve symbol
symbol : class MBeanServerConnection
location: class org.jboss.test.JBossTestServices
public MBeanServerConnection getServer() throws
Exception
^
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestServices.jav
a:205:
c
annot resolve symbol
symbol : class MBeanServerConnection
location: class org.jboss.test.JBossTestServices
protected Object invoke(MBeanServerConnection
server, ObjectName name, String
method, Object[] args, String[] sig)
^
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestCase.java:12
2:
canno
t resolve symbol
symbol : class MBeanServerConnection
location: class org.jboss.test.JBossTestCase
protected MBeanServerConnection getServer() throws
Exception
^
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestSetup.java:1
4:
canno
t resolve symbol
symbol : class MBeanServerConnection
location: package management
import javax.management.MBeanServerConnection;
^
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestSetup.java:7
3:
canno
t resolve symbol
symbol : class MBeanServerConnection
location: class org.jboss.test.JBossTestSetup
protected MBeanServerConnection getServer() throws
Exception
^
C:\JBOSS-~1\jboss-4.0\test\src\main\org\jboss\test\JBossTestServices.jav
a:116:
c
annot resolve symbol
symbol : class MBeanServerConnection
location: class org.jboss.test.JBossTestServices
server =
(MBeanServerConnection)initialContext.lookup(adaptorName);
^
9 errors

BUILD FAILED
The dependent libraries are downloaded and correct
under thirdparty and classpath does contain the paths.

Also re-did the checkout.
In some 3.2 build forums have seen similar errors..

- rgds
Venky

Looking into the ejb timer persistence issue, I have a couple of questions:

* Should timer persistence be enabled by default and let the user override this in the bean descriptor (e.g. <timer-persistence>false</timer-persistence>), or the other way round?

* By changing the "internal" EJBTimerService API are we having the same integration issues with e.g. EJB3 wanting to run on previous jboss versions unchanged? If that is the case, I can add extra methods rather than change existing ones. I don't think we need extension interfaces for something used internally in jboss.

* Since persistence is really a property of a TimerService, at the time of creation, rather than enhancing removeTimerService(..) we could instead offer new createTimerService(..) methods with the additional boolean flag.

On the other hand, shouldn't timer persistence be just a matter of the chosen PersistencePolicy? i.e.

- if the NoopPersistencePolicy -> no persistence whatsoever
- if some other persistence policy is configured -> persistence enabled both for crash recovery and redeployments, which from the discussion, is what users really anticipate.

In the latter case, the persistent image is cleared when user code does a timer.cancel() or we offer some operation over the persistence mbean interface.

I've tried the following changes, just want to make a quick check if I miss something, before I commit this in HEAD.

* The active timers for EJBs are not removed from persistent storage upon undeployment. Setting <timer-persistence> to false (default is true) at bean level, brings back the old behaviour (although I doubt anyone will use this)

* Upon deployment (container start) we'll attempt to restore any persisted timers found for the container (based on its name). A timer maybe found, either because the container had crashed, or because the timer was still active when the ejb was undeployed.

* The persistence policy is no longer responsible for timer restoration. Timers are not restored when the server has completed start-up. They are restored as ejbs are deployed (I assume this is okay since their dependencies must have been satisfied during container.start() ).

* The methods used by EJB3 are still there, although the default in this case is no timer persistence and no restoration (by looking at the code I think restoration from crashes was not working anyway for ejb3). We'll need to call the new EJBTimerService methods to get that functionality, whenever Bill is ready.

* BTW, I see in so many places in the code this pattern:
someMethod()
{
get a dynamic MBean proxy
make a single type-safe call
throw the proxy away
}
Is proxy creation really so cheap? Shouldn't those proxies be cached, or we are just lazy :)

Thanks