directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Quartz integration and LDAP persistence store
Date Sat, 27 Sep 2008 16:54:32 GMT
I'd love to get Derby out - it adds a lot to the footprint.

I can help with the mapping of data structures to LDAP.  As Emmanuel said
the best way is to embellish the page we already have in confluence perhaps
with a section on each data structure and we can write out the quartz schema
for it.

Looking initially at the DB schema you provided Kiran I can see this will be
pretty easy to do.  For starters we will have a quartzTrigger ABSTRACT
objectClass with a quartzTriggerName attribute and a quartzTriggerGroup
attribute.  This can be extended for quartzCronTrigger, quartzBlobTrigger,
quartzSimpleTrigger STRUCTURAL objectClasses.  Under a trigger we can
subordinate the jobs the trigger has fired off.  This is oversimplified I
know but these are the best steps to take to just knock this out.

It will not be that hard to do.  Once we know the schema and namespace
organization it's pretty easy to do and I'm not very worried about the
schema design at all.

Alex

On Sat, Sep 27, 2008 at 12:05 PM, Emmanuel Lecharny <elecharny@gmail.com>wrote:

> Hi Kiran,
>
> first, I suggest that you create a page on the wiki where you put your
> thoughts about Quartz integration, as it will be more easy to look at the
> graphics. (when this page is modified, the dev list is notified)
>
> Kiran Ayyagari wrote:
>
>>
>> Here are some ideas that I have atm
>>
>> 1. Serialize the in-memory data structures used by quartz and reload them
>> after server startup.
>>    (may require a separate partition to store)
>>
> This is clearly an option. Now, we have to express Quartz needed structure
> in a hierarchical way.
>
>>
>> 2. Use an embeddable RDBMS. In this case quartz can directly store data
>> using its inbuilt JdbcStore.
>>    (This may be the last and least preferable option )
>>
> Yep. I would not favor this approach either, but we have to remain open
> minded ... (all in all, we already embed Derby in ADS to manage replication
> :)
>
>
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny
> www.iktek.com
> directory.apache.org
>
>
>

Mime
View raw message