[
https://issues.apache.org/jira/browse/HBASE-17277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15731247#comment-15731247
]
Joep Rottinghuis commented on HBASE-17277:
------------------------------------------
If we want to treat the existing BMImpl as a total black-box, then we should
consider a slightly different pattern. We'd use a decorator pattern where we
would keep track of buffered mutations outside the wrapped BM. The construction
of the wrapperBM would then indeed have to take a BM as an argument.
For the BufferedMutatorParams it would then have to have a setter/getter for a
factory like so:
{code}
package org.apache.hadoop.hbase.client;
/**
* Used to create a
*/
public interface BufferedMutatorFactory {
public BufferedMutator getBufferedMutator(BufferedMutator wrapped);
}
{code}
That way the caller gets to construct their own BM implementation which can
intercept the mutate and flush calls, do the needed to track (and/or flush) and
for the communication with HBase delegate to the wrapped BufferedMutator.
That way no reflection is needed in ConnectionImplementation, and the caller
can pass whatever arguments are needed in the construction of the wrapper BM
(such as connections to HDFS, or whatever else is desired for the spooling).
With this pattern the BufferedMutatorImpl can stay private and change freely.
> Allow alternate BufferedMutator implementation
> ----------------------------------------------
>
> Key: HBASE-17277
> URL: https://issues.apache.org/jira/browse/HBASE-17277
> Project: HBase
> Issue Type: Sub-task
> Reporter: stack
> Assignee: stack
> Attachments: HBASE-17277.master.001.patch,
> HBASE-17277.master.002.patch
>
>
> Allow being able to supply alternate BufferedMutator implementation. For
> example, the parent issue would like to spool writes to the filesystem if
> hbase is down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)