[
https://issues.apache.org/jira/browse/HDDS-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900108#comment-16900108
]
Elek, Marton commented on HDDS-1499:
------------------------------------
Sorry, I am very late in this party.
I found some problem with the create volume (volume creation is not cached) and
I am trying to understand the current design.
bq. well, I was really hoping that the fact that there is a cache is not
visible to the layer that is reading and writing. Is there a reason why that
should be exposed to calling applications?
This was as comment by [~anu] and I had the same question very soon. It was not
clear for me why do we need separated methods for the TypedTable (cached
put/get instead of the simple put/get which may or may not be cached.)
What I expected is to have a Table<KEY,VALUE> implementation where there is an
in-memory map under the hood and a real rocksdb Table.
If I understood well the arguments in the PR (but fix me if I am wrong) It was
not possible as this cache is not a traditional cache. When the value is added
to the cache it may not be committed yet (as the cache is independent from the
write path). It's more like an in memory overlay-table. If something is added
to the in-memory table it should be used a return value.
But in this case the in-memory overlay table seems to be an independent
component. As I can see the TableCache interface is a simplified version of a
key-value table. In the original TypedTable a lot of methods just ignores the
cache and if the cache is not updated manually (as it's not updated with the
put method) the behavior will be inconsistent.
It seems to be more safe to separate the TableCache from TypedTable.
> OzoneManager Cache
> ------------------
>
> Key: HDDS-1499
> URL: https://issues.apache.org/jira/browse/HDDS-1499
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Components: Ozone Manager
> Reporter: Bharat Viswanadham
> Assignee: Bharat Viswanadham
> Priority: Major
> Labels: pull-request-available
> Fix For: 0.4.1, 0.5.0
>
> Time Spent: 12h
> Remaining Estimate: 0h
>
> In this Jira, we shall implement a cache for Table.
> As with OM HA, we are planning to implement double buffer implementation to
> flush transaction in a batch, instead of using rocksdb put() for every
> operation. When this comes in to place we need cache in OzoneManager HA to
> handle/server the requests for validation/returning responses.
>
> This Jira will implement Cache as an integral part of the table. In this way
> users using this table does not need to handle like check cache/db. For this,
> we can update get API in the table to handle the cache.
>
> This Jira will implement:
> # Cache as a part of each Table.
> # Uses this cache in get().
> # Exposes api for cleanup, add entries to cache.
> Usage to add the entries in to cache will be done in further jira's.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
