Integrating cache store with Spring transaction manager

[Valentin Kulichenko]

Igniters,

I'm currently working on this ticket:
https://issues.apache.org/jira/browse/IGNITE-891 and I have a couple of
thoughts about current cache store design. What I don't like about it, is
that we have only sessionEnd callback, but not sessionStart. We assume that
the flow is the following:

   - on each store operation user tries to get a connection from session
   - if connection is there, use it to update or query DB
   - otherwise, create a new connection and attach it to session
   - when sessionEnd is called, do commit or rollback

This is OK for plain JDBC because user can't do anything until he has a
Connection object in hands, so he is FORCED to execute some logic that will
create it if needed. The same goes for Hibernate as there is a Session
object which is similar to Connection in this case.

But Spring (and I believe this is not the only example) is different. Its
transaction manager allows to start a transaction and gives you a handle
which can be used only for commit or rollback. Any operations executed in
the same thread via Spring's APIs (JdbcTemplate, HibernateTemplate, etc.)
will participate in this transaction. So user is not forced to execute the
logic that will start a transaction if it's not started yet. This is
error-prone - a stupid mistake can cause DB operations to execute outside
of transaction.

sessionStart callback will help and will make store API more generic. But
we can't add it directly to store w/o breaking compatibility, so I suggest
to add new interface:

public interface CacheStoreTransactionAware {
    public void onTransactionStart();

    public void onTransactionEnd(boolean commit);
}

A store can optionally implement this interface. If it does,
onTransactionEnd replaces sessionEnd and we also have onTransactionStart.
Otherwise, sessionEnd works as earlier.

sessionEnd can be deprecated in favor of new interface.

Thoughts?

--
Val

[yzhdanov]

Val, I agree with your suggestion.

--Yakov

2015-05-13 5:43 GMT+03:00 Valentin Kulichenko <[hidden email]
>:

> Igniters,
>
> I'm currently working on this ticket:
> https://issues.apache.org/jira/browse/IGNITE-891 and I have a couple of
> thoughts about current cache store design. What I don't like about it, is
> that we have only sessionEnd callback, but not sessionStart. We assume that
> the flow is the following:
>
>    - on each store operation user tries to get a connection from session
>    - if connection is there, use it to update or query DB
>    - otherwise, create a new connection and attach it to session
>    - when sessionEnd is called, do commit or rollback
>
> This is OK for plain JDBC because user can't do anything until he has a
> Connection object in hands, so he is FORCED to execute some logic that will
> create it if needed. The same goes for Hibernate as there is a Session
> object which is similar to Connection in this case.
>
> But Spring (and I believe this is not the only example) is different. Its
> transaction manager allows to start a transaction and gives you a handle
> which can be used only for commit or rollback. Any operations executed in
> the same thread via Spring's APIs (JdbcTemplate, HibernateTemplate, etc.)
> will participate in this transaction. So user is not forced to execute the
> logic that will start a transaction if it's not started yet. This is
> error-prone - a stupid mistake can cause DB operations to execute outside
> of transaction.
>
> sessionStart callback will help and will make store API more generic. But
> we can't add it directly to store w/o breaking compatibility, so I suggest
> to add new interface:
>
> public interface CacheStoreTransactionAware {
>     public void onTransactionStart();
>
>     public void onTransactionEnd(boolean commit);
> }
>
> A store can optionally implement this interface. If it does,
> onTransactionEnd replaces sessionEnd and we also have onTransactionStart.
> Otherwise, sessionEnd works as earlier.
>
> sessionEnd can be deprecated in favor of new interface.
>
> Thoughts?
>
> --
> Val
>

[dsetrakyan]

Instead of deprecation, how about creating CacheSpringStore with required
start and end callbacks?

D.

On Tue, May 12, 2015 at 11:14 PM, Yakov Zhdanov <[hidden email]> wrote:

> Val, I agree with your suggestion.
>
> --Yakov
>
> 2015-05-13 5:43 GMT+03:00 Valentin Kulichenko <
> [hidden email]
> >:
>
> > Igniters,
> >
> > I'm currently working on this ticket:
> > https://issues.apache.org/jira/browse/IGNITE-891 and I have a couple of
> > thoughts about current cache store design. What I don't like about it, is
> > that we have only sessionEnd callback, but not sessionStart. We assume
> that
> > the flow is the following:
> >
> >    - on each store operation user tries to get a connection from session
> >    - if connection is there, use it to update or query DB
> >    - otherwise, create a new connection and attach it to session
> >    - when sessionEnd is called, do commit or rollback
> >
> > This is OK for plain JDBC because user can't do anything until he has a
> > Connection object in hands, so he is FORCED to execute some logic that
> will
> > create it if needed. The same goes for Hibernate as there is a Session
> > object which is similar to Connection in this case.
> >
> > But Spring (and I believe this is not the only example) is different. Its
> > transaction manager allows to start a transaction and gives you a handle
> > which can be used only for commit or rollback. Any operations executed in
> > the same thread via Spring's APIs (JdbcTemplate, HibernateTemplate, etc.)
> > will participate in this transaction. So user is not forced to execute
> the
> > logic that will start a transaction if it's not started yet. This is
> > error-prone - a stupid mistake can cause DB operations to execute outside
> > of transaction.
> >
> > sessionStart callback will help and will make store API more generic. But
> > we can't add it directly to store w/o breaking compatibility, so I
> suggest
> > to add new interface:
> >
> > public interface CacheStoreTransactionAware {
> >     public void onTransactionStart();
> >
> >     public void onTransactionEnd(boolean commit);
> > }
> >
> > A store can optionally implement this interface. If it does,
> > onTransactionEnd replaces sessionEnd and we also have onTransactionStart.
> > Otherwise, sessionEnd works as earlier.
> >
> > sessionEnd can be deprecated in favor of new interface.
> >
> > Thoughts?
> >
> > --
> > Val
> >
>