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
