Yes, please.
https://issues.apache.org/jira/browse/IGNITE-4795
2017-02-28 2:22 GMT+07:00 Denis Magda :
> +1 to Alexander’s proposal.
>
> Alexander, could you wrap the discussion up creating a ticket with
> detailed explanation what to do?
>
> —
> Denis
>
> On Feb 27, 2017, at 9:01 AM, Dmitriy Se
+1 to Alexander’s proposal.
Alexander, could you wrap the discussion up creating a ticket with detailed
explanation what to do?
—
Denis
> On Feb 27, 2017, at 9:01 AM, Dmitriy Setrakyan wrote:
>
> I like the idea of fixing the exception inheritance.
>
> On Mon, Feb 27, 2017 at 1:40 AM, Alexan
I like the idea of fixing the exception inheritance.
On Mon, Feb 27, 2017 at 1:40 AM, Alexandr Kuramshin
wrote:
> I think annotating the methods with @IgniteTransactional is redundant,
> because they are already marked by "throws TransactionTimeoutException/
> TransactionRollbackException/Transa
I think annotating the methods with @IgniteTransactional is redundant,
because they are already marked by "throws
TransactionTimeoutException/TransactionRollbackException/TransactionHeuristicException".
For example, the same approach was used in JavaBeans 1.01 specs [1] with
TooManyListenersExcept
On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura wrote:
> 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.
>
Why do you think it will be confusing?
>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
wrote:
> postgres has the different viewpoint
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
This is even better. Alexandr, could you do this since you already know what’s
transaction and what isn’t?
—
Denis
> On Feb 15, 2017, at 10:50 AM, Dmitriy Setrakyan wrote:
>
> Why not just have @IgniteTransactional annotation and attach it to all the
> transactional methods?
>
> On Wed, Feb 1
Why not just have @IgniteTransactional annotation and attach it to all the
transactional methods?
On Wed, Feb 15, 2017 at 9:48 AM, Denis Magda wrote:
> Alexander,
>
> Thanks for extensive feedback. I do support your idea that we need to
> specify explicitly which methods are transactional and wh
Alexander,
Thanks for extensive feedback. I do support your idea that we need to specify
explicitly which methods are transactional and which aren’t.
> Only after deep multi-thread testing, and consulting with other developers, I
> get know that only get and put methods are running within tran
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 Kura
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 TRANSACTI
12 matches
Mail list logo
