Quartz based on EJB Timer API / CommonJ

[mfry]

As I understand Quartz creates its own threads which is not perfect in a J2EE environment.
Would it be possible to not have Quartz create threads and instead use the EJB Timer API / CommonJ / Weblogic Timer service but still use the rest of Quartz?
Would one have to implement a SchedulerFactory?

Thanks,
Juergen
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=409452&messageID=496958#496958


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[James House]

The simple answer is no.  Which is why it has never been done.

Some of the threads Quartz creates could be reworked to make use of the
container timer threads, but not all of them -- or at least not in any
practical way.  I've put a lot of thought into it over the years, and
probably a person could get it working but it would end up being such a
different code base as to not be able to be used in a non-container
(stand-alone) application, and it would likely not be able to be as
responsive/scalable.    The explanation for all this would be quite
lengthly to type up, so you'll either have to take my word for it, or
investigate it yourself ;-).


That said, I don't know of any environment where Quartz's creation of
threads actually causes a problem.  I know of its successful usage in
Weblogic, Tomcat, WebSphere, Jetty, Resin, JBoss, ...   Note that the
major restriction on custom threading in an appserver actually most
directly relates to the necessity of not blocking or locking one of the
appserver's own threads (e.g. a thread servicing and EJB call) or
spawning a thread from one of the app server threads.  The other area in
which things can be touchy is with "context" (authentication,
transaction, class loading, etc. context) that ought to be "carried" on
a thread when making calls on components - that context is put on the
container's threads by the container itself as it creates and manages
the threads (spawning a thread from one of the containers threads can
propagate some non-specific bits of the context, leading to weird
things).  A custom threads can typically gain this context by opening an
InitialContext and/or working with the TransactionManager - which are
both things that Quartz currently does.


james


Juergen Weber wrote:

> As I understand Quartz creates its own threads which is not perfect in a J2EE environment.
> Would it be possible to not have Quartz create threads and instead use the EJB Timer API / CommonJ / Weblogic Timer service but still use the rest of Quartz?
> Would one have to implement a SchedulerFactory?
>
> Thanks,
> Juergen
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=409452&messageID=496958#496958
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mfry]

I am just starting to investigate how to have a Timer trigger EJB code, so I hope I'll be forgiven to ask naive questions (instead of investigating or just believing you ;-)

As I understand (http://e-docs.bea.com/wls/docs100/commonj/commonj.html)
commonj.timers.TimerListener.timerExpired()
or javax.ejb.TimedObject.ejbTimeout()
(http://www.onjava.com/pub/a/onjava/2004/10/13/j2ee-timers.html)

are just callbacks from a Timer Thread inside the Appserver.

Quartz must have a Timer Thread itself (QuartzSchedulerThread ?, I guess) that makes callbacks to the actual scheduling code that fires the Jobs.

So in the stand-alone case Quartz would still need its own Timer Thread but in the J2EE Case it would delegate to the Appserver, so it would have ThreadBasedScheduler, CommonJBasedScheduler and EJBBasedScheduler.

Too naive?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=409452&messageID=497056#497056


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mfry]

Juergen,

I am running into this myself and would have liked to see CommonJ Workmanager integration, with the scheduling being done by quartz. The reason being that I could then gain access to java:comp/UserTransaction from within an quartz job.
I know that spring does provide LocalTaskExecutorThreadPool which can delegate to WorkManagerTaskExecutor. However I still get the error from websphere 6.1.0.13 :
 NMSV0310E: A JNDI operation on a "java:" name cannot be completed because ...
Seems that the the j2ee context is gone??
When I use commonJ directly I don't get this error, but then I don't have quartz cron scheduling...
Could you explain why this doesn't work properly, a simple commonj threadpool delegate?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=409452&messageID=540634#540634


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mfry]

Looking into this some more..

I guess the scheduler thread runs unmanaged hence no context is being passed when the commonj threadpool is used. Would it not be possible to run the scheduler thread managed, ie. from the commonj threadpool itself?

Regards.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=409452&messageID=540751#540751


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...