[ApacheDS] Quartz integration and LDAP persistence store

[Kiran Ayyagari <ay...@gmail.com>]

hi guys,

    I have been working on finding ways to integrate quartz into the 
server and mainly on the feature to store the
    quartz scheduling data a.k.a Quartz LDAP store.
  
    Currently quartz has two kinds of stores, In-memory and RDBMS. 
Quartz uses 12 tables!! to store data in
    RDBMS (attached the pdf of the ER diagram)

    The  LDAP store is not a separate store but an interface to store 
the data in the given partition like
    ou=system. How can we represent this relational data per row in a 
single LDAP entry?

     thoughts?

-- 
Kiran Ayyagari

Re: [ApacheDS] Quartz integration and LDAP persistence store

[Alex Karasulu <ak...@apache.org>]

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

Re: [ApacheDS] Quartz integration and LDAP persistence store

[Emmanuel Lecharny <el...@gmail.com>]

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

Re: [ApacheDS] Quartz integration and LDAP persistence store

[Kiran Ayyagari <ay...@gmail.com>]

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)

 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 )

-- 
Kiran Ayyagari
 
Kiran Ayyagari wrote:
> hi guys,
>
>    I have been working on finding ways to integrate quartz into the 
> server and mainly on the feature to store the
>    quartz scheduling data a.k.a Quartz LDAP store.
>  
>    Currently quartz has two kinds of stores, In-memory and RDBMS. 
> Quartz uses 12 tables!! to store data in
>    RDBMS (attached the pdf of the ER diagram)
>
>    The  LDAP store is not a separate store but an interface to store 
> the data in the given partition like
>    ou=system. How can we represent this relational data per row in a 
> single LDAP entry?
>
>     thoughts?
>