tephra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Varun Rao <varunrao0...@gmail.com>
Subject Re: SELECT after INSERT shows missing data
Date Tue, 11 Dec 2018 18:21:12 GMT
Thanks for the quick reply Andreas -

Spring's Propagation.REQUIRED option is being used, so our understanding is
that a nested @Transactional will re-use the existing transaction context
if one exists (we also need the two operations to happen together, as one
transaction):
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Propagation.html#REQUIRED

This is intermittent behavior - the first insert has always been visible
from checkToEnsureObj1WasInserted() other than the single failure that was
observed last week (And we expect the first insert to be visible within the
transaction context given snapshot isolation and the Phoenix
documentation:  https://phoenix.apache.org/transactions.html)

Just to confirm, as we understand it Tephra provides snapshot isolation
(rather than the ANSI sql92 isolation levels.. read_committed,
repeatable_read, serializable).  So the fact that we are passing
READ_COMMITTED at the Spring level should not be relevant to the isolation
that Tephra provides, is that accurate?

Is there particular logging that we can look for (or enable, if needed) to
confirm:
1) our transactions are in-fact using Tephra snapshot isolation
2) any lower level Tephra transaction details which may help us
troubleshoot this issue, if and when it occurs again?

Thanks very much

On Tue, Dec 11, 2018 at 12:05 PM Andreas Neumann <anew@apache.org> wrote:

> Hey Varun,
>
> I think the issue is that your code starts the second transaction before
> the first one has committed (inside the outer @Transactional). Because of
> snapshot isolation, the second transaction cannot see the writes from the
> first one. I see tw ways to make it work:
>
> 1. Remove the @Transactional from insertInner(). That way it is part of the
> same transaction and will see the write of obj1.
> 2. Serialize the transactions. It should work if rewrite your code to
> something like this:
>
> void insertBoth(Object obj, Object obj2) throws someException {
> insertOuter(obj1);
> insertInner(obj1, obj2);
> }
>
> @Transactional
> void insertOuter(Object obj1, Object obj2) throws SomeException {
> // Spring call to insert obj1 into Phoenix transactional table1
> }
>
> @Transactional
> void insertInner(Object obj) throws SomeException {
> checkToEnsureObj1WasInserted() // ** THIS FAILS
> ... // code to insert object 2
> }
>
> Cheers -Andreas.
>
> On Tue, Dec 11, 2018 at 7:05 AM Varun Rao <varunrao0919@gmail.com> wrote:
>
> > Hello,
> >
> > We have an application that issues two sequential inserts within the same
> > Phoenix/Tephra transaction.  Before the second insert, a check is
> performed
> > to ensure data from the first insert is available (select ...).  This
> check
> > failed once in production (an intermittent problem which has not been
> > reproduced).  Phoenix/Tephra is being accessed through
> > Spring (which uses Java Transaction API) with 'read committed' and
> > 'propagation.required' options.  The code is similar to the following:
> >
> > @transactional
> > void insertOuter(Object obj1, Object obj2) throws SomeException {
> > // Spring call to insert obj1 into Phoenix transactional table1
> > insertInner(obj2)
> > }
> >
> > @Transactional
> > void insertInner(Object obj) throws SomeException {
> > checkToEnsureObj1WasInserted() // ** THIS FAILS
> > ... // code to insert object 2
> > }
> >
> > We expect to see that subsequent write operations within the same Phoenix
> > transactions are guaranteed to see the results of prior operations (the
> > second write will have access to the first write)
> >
> > 1)  Should Java Spring be compatible with Phoenix/Tephra?
> > 2)  Is there a particular Phoenix/Tephra logging configuration that can
> be
> > enabled to capture additional transaction-specific information, such as
> > when commits or rollbacks occur?
> >
> > Thanks very much
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message