polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: Quartz spike
Date Thu, 17 Dec 2015 22:35:43 GMT
Once again I feel your pain Niclas. I recall coming up to the same
conclusion: Quartz is not extensible enough and tied to JDBC.

XA/UoW orchestration sounds like something that could open up for a lot
of integration, but I won't go down that road myself.

I also still think that this library is a good idea. I might take a stab
at it at some point or if the need arise in what I do.

To be continued

Niclas Hedhman a écrit :
> There are quite a few negative views of Quartz online. And possibly it
> isn't the right way to go. But I will push the branch in case someone wants
> to take a look at what I tried.
> Cheers
> Niclas
> On Tue, Dec 1, 2015 at 2:06 AM, Kent Sølvsten <kent.soelvsten@gmail.com>
> wrote:
>> A shame :-(
>> I think you should push it somewhere to preserve it for now.
>> My gut feeling is that (some day) we should improve enterprise
>> integration ...
>> something involving coordination between an XA transaction and a UOW
>> - and then use a JDBCJobStore with global transactions.
>> That could potentially solve a lot of problems in EE deployments - and a
>> RamJobStore might be sufficient for SE (standalone) deployments.
>> But i admit, I dont know how (yet) to accomplish that integration -
>> implementing an XA resource is probably too complicated and hopefully
>> unnecessary.
>> /Kent
>> Den 29-11-2015 kl. 05:45 skrev Niclas Hedhman:
>>> Gang,
>>> I have now spent too many weekends on the Scheduler library.
>>>   a. What we have doesn't work as expected.
>>>   b. I have not been able to fix it.
>>>   c. I have tried to use Quartz by re-implementing a JobStore, backed by
>>> our persistence. It is highly complicated. Quartz have not managed to
>>> separate the concerns well enough, and too much JDBC assumptions are in
>>> place. I give up on this. I can push my local branch on what I have done,
>>> if someone is interested in picking this up and run with it.
>>>   d. Other hacks are possible, but simply feels utterly wrong. Having a
>> RAM
>>> based JobStore, and try to populate that from our persistence by
>> listening
>>> in on events MIGHT work. I am not going to try.
>>> I still think that the library is an excellent idea, and wish that we
>> could
>>> get it to work. But I think I need to move on to other things to fix.
>> This
>>> is simply beyond me.
>>> Any feedback?
>>> Cheers

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message