clear 2nd cache before commit cause issue

[LeoShi]

Hi, I've met an issue that the db record was updated but related cache still stale in some concurrent cases. I dig into the source code, find the implement of beforeCommit method in SqlSessionUtils.java:

 public void beforeCommit(boolean readOnly) {
    // Connection commit or rollback will be handled by ConnectionSynchronization or
    // DataSourceTransactionManager.
    // But, do cleanup the SqlSession / Executor, including flushing BATCH statements so
    // they are actually executed.
    // SpringManagedTransaction will no-op the commit over the jdbc connection
    // TODO This updates 2nd level caches but the tx may be rolledback later on! 
    if (TransactionSynchronizationManager.isActualTransactionActive()) {
      try {
        if (LOGGER.isDebugEnabled()) {
          LOGGER.debug("Transaction synchronization committing SqlSession [" + this.holder.getSqlSession() + "]");
        }
        this.holder.getSqlSession().commit(); //This line will delete 2nd level cache.
      } catch (PersistenceException p) {
        if (this.holder.getPersistenceExceptionTranslator() != null) {
          DataAccessException translated = this.holder
              .getPersistenceExceptionTranslator()
              .translateExceptionIfPossible(p);
          if (translated != null) {
            throw translated;
          }
        }
        throw p;
      }
    }
  }

I guess this.holder.getSqlSession().commit(); should not be to executed in beforeCommit since it would delete the cache before db commit. and it may cause the issue like I met. FaceBook wrote a paper to explain that the right way should be delete the cache after commit . (https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf)
(https://www.quora.com/Why-does-Facebook-use-delete-to-remove-the-key-value-pair-in-Memcached-instead-of-updating-the-Memcached-during-write-request-to-the-backend)

So I guess maybe we can move this.holder.getSqlSession().commit(); into afterCompletion to solve this problem?

[vlastimil-dolejs]

Hi,
I've hit the same issue. In my case, we do some selects, simple inserts and batch inserts inside of the transaction. The batch inserts are performed in DB on transaction commit. But the transactional cache is committed before this happens. If the batch insert fails in DB, the transaction is rollbacked but not the cache. So the cache contains stale elements created (and selected) during the transaction.

Is there any reason not to commit 2nd level cache after commit as suggested by LeoShi?