>From my point of view @IgniteTransactional annotation is redundant entity which will just confuse and lead to questions like "How to use this annotation?" I think documention update is better way.
On Wed, Feb 15, 2017 at 1:50 PM, Evgeniy Stanilovskiy <[email protected]> wrote: > postgres has the different viewpoint, i hope. > > https://www.postgresql.org/docs/9.1/static/transaction-iso.html > > Read Committed Isolation Level > > Read Committed is the default isolation level in PostgreSQL. When a > transaction uses this isolation level, a SELECT query (without a FOR > UPDATE/SHARE clause) sees only data committed before the query began; it > never sees either uncommitted data or changes committed during query > execution by concurrent transactions. In effect, a SELECT query sees a > snapshot of the database as of the instant the query begins to run. However, > SELECT does see the effects of previous updates executed within its own > transaction, even though they are not yet committed. > > >> Alexandr, >> >> If you PUT some value within transaction, this is absolutely normal that >> you will see it on successive GET in the _same_ transaction. DIRTY_READ is >> a different thing - it allows reads of not-yet-committed changes from >> _another_ transaction. >> >> On Wed, Feb 15, 2017 at 9:41 AM, Alexandr Kuramshin <[email protected]> >> wrote: >> >>> After doing some tests with transactions I've found transactions work not >>> as expected after reading the documentation [1]. >>> >>> First of all, nowhere's written which methods of the cache are >>> transactional and which are not. Quite the contrary, after reading >>> documentation we get know that each TRANSACTIONAL cache is fully >>> ACID-compliant without exceptions. >>> >>> Only after deep multi-thread testing, and consulting with other >>> developers, >>> I get know that only get and put methods are running within transaction, >>> but iterator and query methods are running outside (in autonomous) >>> transaction with READ_COMMITTED isolation level. >>> >>> Later I've understood that only methods throwing >>> TransactionTimeoutException/TransactionRollbackException/ >>> TransactionHeuristicException >>> are fully transactional. I think all methods on page [2] should be >>> directly >>> described - are they transactional or not. Btw, why these exceptions are >>> not derived from the common base class, e.g. TransactionException? >>> >>> Secondary, using the transactional get() method inside the READ_COMMITTED >>> transaction we expect to get the committed value, as the documentation >>> [1] >>> claims: >>> >>> * READ_COMMITTED - Data is read without a lock and is never cached in the >>> transaction itself. >>> >>> Ok, but what about put()? After doing the put() a new value, we get >>> successive reads of the new value, that is actually DIRTY READ. Hence the >>> value is cached within transaction. It's not documented behavior. >>> >>> [1] https://apacheignite.readme.io/docs/transactions >>> >>> [2] >>> https://ignite.apache.org/releases/1.8.0/javadoc/org/ >>> apache/ignite/IgniteCache.html >>> >>> -- >>> Thanks, >>> Alexandr Kuramshin
