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