Re: Quartz spike

[Niclas Hedhman <ni...@hedhman.org>]

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 <ke...@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
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Quartz spike

[Paul Merlin <pa...@nosphere.org>]

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 <ke...@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
>
>