[
https://issues.apache.org/jira/browse/DERBY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563644#action_12563644
]
Dibyendu Majumdar commented on DERBY-3351:
------------------------------------------
I was troubled by the fact that the Monitor implementation looks for
org/apache/derby/modules.properties in the classpath, and the module.properties
file that is found contains modules that are a mix from Language level and
Store level modules. Therefore, by default, it will try to always load these.
In a situation where the Store is replaced, or a different Store is used, this
may not be desirable.
The references to the services.io package is problematic for similar reasons. A
Store replacement may have its own method of managing serialization, so it
would be better if the Monitor package was blind to the type of serialization
mechanism used. One option is to have a common Class/Object registry that is
used by both monitor and the io services, rather than creating a dependency
between the two.
I have another question - the StorageFactoryService contains calls to java.io
package as well as the storageFactory abstraction. Shouldn't all IO be
delegated to storageFactory components? It seems that even if a memory based
storageFactory is used, the StorageFactoryService will still require some file
IO.
Thank you for answering my questions.
> 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.
