[
https://issues.apache.org/jira/browse/DERBY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562798#action_12562798
]
Dibyendu Majumdar commented on DERBY-3351:
------------------------------------------
Hi Dan,
Thanks for the input. I agree that it is important to define the role of the
Store at a high level.
In my view, the role of the Store should be to perform:
Transaction logging
Transaction Management
Table & Index creation & maintenance
Locking
Buffer Cache management
IO
Many of these modules can be reusable in their own right.
But the Store boundary still makes sense to me, because of following reasons:
Firstly there is a natural distinction between the language (SQL) and the
engine (Store). I suppose this distinction must have driven the original design.
Secondly some of the Store modules are likely to be highly interdependent. For
instance, it is possible to imagine a storage engine that supports
multi-version concurrency. Such an engine would probably have a different
implementation of the transaction manager and the lock manager. I think that
making transaction management re-usable is particularly hard because there is
so much dependency on it - how logging is done, how recovery is done, how
locking is done.
Was the original intention that Store should be usable on its own right? That
is the other side of the coin, in the sense that the Store boundary naturally
maps to a non-SQL dbms.
> 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.
