[ApacheDS] Quartz integration and LDAP persistence store

[Kiran Ayyagari]

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

[Kiran Ayyagari]

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?
>

[Emmanuel Lecharny-3]

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

[Alex Karasulu]

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

[Kiran Ayyagari]

 The schema I have sent before was just to show the number of tables and their relationship.
 I have attached the complete schema table structures to the page at http://hemuu.notlong.com/



Alex Karasulu wrote:

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