ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Integrating cache store with Spring transaction manager
Date Wed, 13 May 2015 02:43:10 GMT

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.



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