EJB timer built on JCA timer SPI abstraction

[starksm64]

Again there is a move to further fragment timer services in that an ejb timer implementation based on quartz that actually wants to expose quartz as the jboss timer SPI. This is not going to happen as there has been zero discussion about how this relates to the mess of timers we have, how this integrates with other server aspects such as security, transactions, persistence, etc.

I want a timer SPI that lives under JCA as the implementation detail to which other timer consumers write to.

[wolfc]

As I've currently set it up the Quartz API is not exposed to either the bean container or the bean developer during compile time. I've got a complete facade package org.jboss.ejb3.timerservice. Also the Quartz API is not exposed during run time to remote clients so it should not be needed on the classpath.

Any extensions we want in the timer service are purely functional and not Quartz API extensions, so we would get an interface JBossTimerService which extends javax.ejb.TimerService for creating (for example) cron timers.

[wolfc]

This still leaves the question: is Quartz a good implementation for an SPI?

Pros:
- working popular scheduler package

Cons:
- has got a seriously outdated persistency mechanism, should have Hibernate (especially if Seam is going to be involved)
- has got a 'broken' semaphore mechanism which relies on certain database locking tricks (not available in Hypersonic for one) and an unmanaged datasource (hard to set up)

Because of the way semaphore is implemented I suspect a high performance hit on the database with lots of timers and a lot of stalemate threads on the app server.

I haven't looked into thread management in Quartz yet. Adrian made a good point of requiring the app server to be in control all the time.

[starksm64]

All of this has to be pluggable, or no, its not a good implementation. Steal the scheduling config elements and move on.

[bill.burke]

All of this has to be pluggable, or no, its not a good implementation. Steal the scheduling config elements and move on.

I disagree. Because Quartz is popular, I want to be able to use Quartz APIs, interfaces, and datastructures. Pluggable is shit. Nobody is ever going to write a plugin and it serves zero use for us.

[bill.burke]

"wolfc" wrote:
This still leaves the question: is Quartz a good implementation for an SPI?

Pros:
- working popular scheduler package

Cons:
- has got a seriously outdated persistency mechanism, should have Hibernate (especially if Seam is going to be involved)
- has got a 'broken' semaphore mechanism which relies on certain database locking tricks (not available in Hypersonic for one) and an unmanaged datasource (hard to set up)

Because of the way semaphore is implemented I suspect a high performance hit on the database with lots of timers and a lot of stalemate threads on the app server.

I haven't looked into thread management in Quartz yet. Adrian made a good point of requiring the app server to be in control all the time.

For the semaphore stuff, you're talking about in a clustered environment right? What if instead we deployed the Quartz service as an HA Singleton? Then it would only run on one machine.

The move to a Hibernate abstraction sounds like a good idea.

Again, I can't state this more clearly. I don't think we should be writing any abstraction for Quartz, but rather using it directly where EJB Timer et. al. does not have a good API. There's no reason we can't use the Quartz interfaces as our SPI.

[starksm64]

Then the ESB cannot use this form of timer service. Get over pushing the quartz api as the timer service. Its not going to happen.

[bill.burke]

Then the ESB cannot use this form of timer service. Get over pushing the quartz api as the timer service. Its not going to happen.

I doubt the ESB cannot use this form of service. Even so, this idea that everything has to be unified is silly.

And no, I won't give it up, because well, we're going to do it anyways.

[starksm64]

ejb3 will not go GA until its using the timer SPI Weston is working on. Instead of stating quartz is the timer SPI, work with Weston to ensure that the SPI can be used for both the spec defined requirements as well as the extensions desired.

[dimitris]

Dump question, but can you plugin to Quartz your own thread pool?

[wolfc]

Create a class which implements ThreadPool and use that class in the SchedulerFactory.

http://www.opensymphony.com/quartz/api/org/quartz/spi/ThreadPool.html

[bill.burke]

"wolfc" wrote:
Create a class which implements ThreadPool and use that class in the SchedulerFactory.

http://www.opensymphony.com/quartz/api/org/quartz/spi/ThreadPool.html

you can also use a jboss datasource.

[bill.burke]

I give up. You win Scott. Sacha and Carlo (the actual implementer) agree with you so poopoo on me. Carlo will finish what he has so that we have something usable in E-EJB3 until JCA Timer is completed.