We also should define savepoint behavior and API rules for each of the
transaction concurrency and isolation types.
* Should rollbackToSavepoint() always release locks or clear saved
optimistic versions?
* Are forward-rollbacks allowed, e.g.
try (Transaction tx = ignite.transactions().txStart()) {
c.put(1, 1);
tx.savepoint("sp1");
c.put(2, 2);
tx.savepoint("sp2")
c.put(3, 3);
tx.rollbackToSavepoint("sp1");
c.put(4, 4);
tx.rollbackToSavepoint("sp2"); // Is this allowed?
tx.commit();
}
2016-11-07 13:47 GMT+03:00 Sergey Kozlov <skoz...@gridgain.com>:
> Hi, Yakov
>
> I suppose it's very very handy feature.
> My two cents are following:
> - number of savepoints may be more than one per transaction
> - what's about RELEASE SAVEPOINT statement?
>
>
> On Mon, Nov 7, 2016 at 11:24 AM, Yakov Zhdanov <yzhda...@apache.org>
> wrote:
>
> > Guys,
> >
> > Let's think of implementing savepoints for Ignite transactions. For me,
> > this is not too hard to do.
> >
> > Having "savepoints" seems to be pretty handy. Please consider the
> following
> > snippet.
> >
> > ignite.transactions.;
> > INSERT INTO table1 VALUES (1);
> > SAVEPOINT my_savepoint;
> > INSERT INTO table1 VALUES (2);
> > ROLLBACK TO SAVEPOINT my_savepoint;
> > INSERT INTO table1 VALUES (3);
> > COMMIT;
> >
> > Which should result in values 1 and 3 inserted to table1.
> >
> > In Ignite, I think, it would be like the following (preserving the same
> > behavior as above).
> >
> > Ignite ignite = ....;
> > IgniteCache<Integer, Integer> c = ....;
> >
> > try (Transaction tx = ignite.transactions().txStart()) {
> > c.put(1, 1);
> >
> > tx.savepoint("mysavepoint");
> >
> > c.put(2, 2);
> >
> > tx.rollbackToSavepoint("mysavepoint");
> >
> > c.put(3, 3);
> >
> > tx.commit();
> > }
> >
> > As far as implementation complexity I would give 2 weeks ballpark.
> >
> > 5 days - API design and implementation for different types of
> transactions
> > - savepoint implementation for local transaction objects
> > - rollback implementation for different types of transactions - drain
> local
> > tx buffers, release remote locks for pessimistic transactions, etc.
> >
> > 5 days - testing, benchmarking, fixing issues.
> >
> > Please leave your comments here. I will file a ticket after we discuss
> this
> > and put our summary to it.
> >
> > Thanks!
> >
> > --Yakov
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>
