db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-3351) Implement a Pluggable Storage Engine Architecture in Derby
Date Wed, 30 Jan 2008 07:38:34 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563875#action_12563875
] 

jorgenlo edited comment on DERBY-3351 at 1/29/08 11:38 PM:
----------------------------------------------------------------

Hi Dibyendu,

I have recently added an alternative implementation (i.e. a new module) of the Database interface.
The new module is called SlaveDatabase and can be found in trunk but not in the official derby
releases yet. I'll use the Database service as an example to shed some light on how the monitor
works. 

There are now two implementations of the Database interface in modules.properties[1], and
when the Monitor is asked to boot a database, it has to chose which of these modules to use.
The Monitor knows from modules.properties that there are two possible implementations, and
asks the first one (seemingly random order) if it should be used by calling it's  canSupport
method. The method call either returns true, in which case Monitor decides to go for that
module, or it returns false which makes the Monitor repeat the process with the next module.
Thus, by making the canSupport methods of the different modules of a service mutually exclusive,
you have full control of which module is chosen by Monitor when it boots a service.

If you haven't read it already, I suggest you have a look at the class javadoc in org.apache.derby.iapi.services.monitor.Monitor.

Hope this helps.

[1] 
derby.module.database=org.apache.derby.impl.db.BasicDatabase and
derby.module.database.slave=org.apache.derby.impl.db.SlaveDatabase

      was (Author: jorgenlo):
    Hi Dabyendu,

I have recently added an alternative implementation (i.e. a new module) of the Database interface.
The new module is called SlaveDatabase and can be found in trunk but not in the official derby
releases yet. I'll use the Database service as an example to shed some light on how the monitor
works. 

There are now two implementations of the Database interface in modules.properties[1], and
when the Monitor is asked to boot a database, it has to chose which of these modules to use.
The Monitor knows from modules.properties that there are two possible implementations, and
asks the first one (seemingly random order) if it should be used by calling it's  canSupport
method. The method call either returns true, in which case Monitor decides to go for that
module, or it returns false which makes the Monitor repeat the process with the next module.
Thus, by making the canSupport methods of the different modules of a service mutually exclusive,
you have full control of which module is chosen by Monitor when it boots a service.

If you haven't read it already, I suggest you have a look at the class javadoc in org.apache.derby.iapi.services.monitor.Monitor.

Hope this helps.

[1] 
derby.module.database=org.apache.derby.impl.db.BasicDatabase and
derby.module.database.slave=org.apache.derby.impl.db.SlaveDatabase
  
> Implement a Pluggable Storage Engine Architecture in Derby
> ----------------------------------------------------------
>
>                 Key: DERBY-3351
>                 URL: https://issues.apache.org/jira/browse/DERBY-3351
>             Project: Derby
>          Issue Type: New Feature
>          Components: Services, SQL, Store
>            Reporter: Dibyendu Majumdar
>            Assignee: Dibyendu Majumdar
>
> My aim is to create a pluggable storage engine architecture for Derby, so that the default
store implementation can be replaced with alternative storage engines. I have created my own
storage engine which I would like to use with Derby's SQL layer, so that is a motivation.
But I also think that this will benefit the community, and could lead to a pluggable storage
engine architecture similar to that of MySQL.
> I am not yet sure where the storage engine boundary should lie. I would welcome input
in this area.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message