[
https://issues.apache.org/jira/browse/PHOENIX-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617265#comment-14617265
]
Jan Fernando commented on PHOENIX-1954:
---------------------------------------
I'm don't think that will work but maybe I am missing something :)
The issue stems from the fact that there are 2 incrementValue() methods on
Sequence.java that that executed in succession and invoked from different JDBC
methods. The flow is:
1) Execute expression SELECT NEXT <n> VALUES FOR <seq> and update sequence
on the server via stmt.executeQuery()
2) Read back values from expression NEXT <n> VALUES FOR <seq> via
rs.next() and rs.getInt()
The calls are:
1) There is incrementValue() that processes the results of the RPC call that
runs within the code synchronized on Sequence.lock() and is part of the flow
that executes the expression.
{code}
public long incrementValue(Result result, ValueOp op, long numToAllocate)
{code}
2) There is incrementValue() that is invoked when the client code executes
rs.next() and called via SequenceTuple.incrementSequenceValues() and is purely
client side code and it is here were we actually need to read the start value
for the bulk allocated range.
{code}
public long incrementValue(long timestamp, ValueOp op, long numToAllocate)
{code}
For this case we need to return the start value from the allocation that
happened which may not be the same as currentValue if NEXT VALUE FOR has been
executed in between. Since it's here that we need to return the start value we
have to cache it on the client separately from currentValue. At the time we get
the value back from the server with #1, since we are still within the
synchronized code, current value on the Result object is correct. However we
read it back asynchronously in #2 we have to store it on the client.
[~jamestaylor] Thoughts?
> Reserve chunks of numbers for a sequence
> ----------------------------------------
>
> Key: PHOENIX-1954
> URL: https://issues.apache.org/jira/browse/PHOENIX-1954
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Lars Hofhansl
> Assignee: Jan Fernando
> Attachments: PHOENIX-1954-rebased.patch, PHOENIX-1954-wip.patch,
> PHOENIX-1954-wip2.patch.txt, PHOENIX-1954-wip3.patch, PHOENIX-1954-wip4.patch
>
>
> In order to be able to generate many ids in bulk (for example in map reduce
> jobs) we need a way to generate or reserve large sets of ids. We also need to
> mix ids reserved with incrementally generated ids from other clients.
> For this we need to atomically increment the sequence and return the value it
> had when the increment happened.
> If we're OK to throw the current cached set of values away we can do
> {{NEXT VALUE FOR <seq>(,<N>)}}, that needs to increment value and return the
> value it incremented from (i.e. it has to throw the current cache away, and
> return the next value it found at the server).
> Or we can invent a new syntax {{RESERVE VALUES FOR <seq>, <N>}} that does the
> same, but does not invalidate the cache.
> Note that in either case we won't retrieve the reserved set of values via
> {{NEXT VALUE FOR}} because we'd need to be idempotent in our case, all we
> need to guarantee is that after a call to {{RESERVE VALUES FOR <seq>, <N>}},
> which returns a value <M> is that the range [M, M+N) won't be used by any
> other user of the sequence. My might need reserve 1bn ids this way ahead of a
> map reduce run.
> Any better ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
