db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3351) Implement a Pluggable Storage Engine Architecture in Derby
Date Sat, 26 Jan 2008 17:21:34 GMT

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

Daniel John Debrunner commented on DERBY-3351:

Just to add providing a clean pluggable api is good project, but potentially a very big project.
It might be best to attack the various modules one at a time, as far as possible. E.g. a better
transaction management system would be a good first start. Some o-o based that allowed clients
(e.g. the jdbc and sql) layers to register events at commit and rollback time. Currently there
is too much code that adds extra logic to the commit path (in multiple places). I discussed
this on the mailing last about a year ago, I'll look for the links. The general idea would
   - transaction management - keeping track of which transactions are active - may be independent
of the store
   - transaction durability - function of the store
   - transaction api for sql & jdbc layer (event based callback scheme) -may be independent
of the store (function of transaction management)

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

View raw message