Dmitriy,
Yes, this achieves the same purpose, thanks for hint.
Updated PR to use strictly setRollbackOnly().
ср, 11 июл. 2018 г. в 4:17, Dmitriy Setrakyan :
> Anton,
>
> Committing or rolling back from MXBean is OK, because it is not a listener,
> but a direct invocation. However, it is not OK t
Anton,
Committing or rolling back from MXBean is OK, because it is not a listener,
but a direct invocation. However, it is not OK to allow synchronous
rollback from a filter or a listener. The only action you can do from a
listener is setRollbackOnly() which will cause the transaction to be rolled
Dmitriy,
Rollback from remote filter uses rollbackOnlyProxy [1], that's a special
proxy allows rollback from another thread.
It was specially designed to rollback transactions by "label" if necessary.
So, I'm just finishing "label feature" to make it more useful at real
production.
Here's the exa
Anton, how do you plan to rollback the transaction from a remote filter?
Are you planning to call setRollbackOnly()? Calling rollback() or commit()
from any filter or listener should not be allowed.
D.
On Tue, Jul 3, 2018 at 1:55 AM, Anton Vinogradov wrote:
> Dmitriy, Yakov,
>
> I've finalized
Dmitriy, Yakov,
I've finalized design and prepared the solution [1].
1) Only events from GridNearTxLocal are registered now.
List of possible events:
public static final int[] EVTS_TX = {
EVT_TX_STARTED,
EVT_TX_COMMITTED,
EVT_TX_ROLLED_BACK,
EVT_TX_SUSPENDED,
Anton, we are very far from agreement. I think it makes sense to step back,
come up with a clean design and propose it again.
On Fri, Jun 1, 2018 at 12:59 PM, Anton Vinogradov wrote:
> Dmitriy,
>
> Unfortunately, we have more than 2 types of txs, full list is
>
> GridDhtTxLocal
> GridDhtTxRemote
Dmitriy,
Unfortunately, we have more than 2 types of txs, full list is
GridDhtTxLocal
GridDhtTxRemote
GridNearTxLocal
GridNearTxRemote
BTW, We have no clear documentation about behaviour and difference.
I created an issue [1] to solve this, but seems no one interested :(
1) What I see is that
I do not like the inconsistent behavior between different transaction
events. I now feel that we need to separate events between Near TX and
Remote TX, and maybe focus on the Near TX for now.
How about we only add events for the Near TX and have a consistent behavior
across all Near TX events. I w
Dmitriy,
1) EVT_TX_PREPARED were added this morning to check event generation on
remote nodes :)
2) Only GridNearTxLocal has label now, that's the implementation we
currently have. It can be improved if necesary, I think.
So, actually, label always available at
- EVT_TX_STARTED,
- EVT_TX_SUSPENDE
Ok, sounds good.
I till have more comments:
1. I think you have missed EVT_TX_PREPARED event
2. I am still very confused with your comment on "label()" method. Why
is the label not propagated to remote nodes? What happens when users call
this "label()" method for other TX events, not
Dmitriy,
In that case there will be no chances to listen only tx creation events
without slowing down the system on other tx events creation and filtering.
All events are processed at same thread where tx changes the state, so, we
have to have the way to decrease potential slowdown.
I made it sim
Anton,
Why not just have one transaction event: EVT_TX_STATE_CHANGED?
D.
On Thu, May 31, 2018 at 9:10 AM, Anton Vinogradov wrote:
> Dmitriy,
>
> Thanks for your comments!
>
> I've updated design to have
>
> public class TransactionStateChangedEvent extends EventAdapter {
> private Transact
Dmitriy,
Thanks for your comments!
I've updated design to have
public class TransactionStateChangedEvent extends EventAdapter {
private Transaction tx;
}
also I specified following set of possible events
public static final int[] EVTS_TX = {
EVT_TX_STARTED,
EVT_TX_COMMITTED,
EVT_TX_ROLLED_
Anton,
We cannot have TransactionStartedEvent without having events for all other
transaction states, like TransactionPreparedEvent,
TransactionCommittedEvent, etc. Considering this, I sill do not like the
design, as we would have to create many extra event classes.
Instead, I would suggest that
Dmitriy,
I fixed design according to your and Yakov's comments, thanks again for
clear explanation.
>> 1. You use internal API in public event, i.e. you cannot have user
>> accessing to IgniteInternalTx instance through TxEvent.
Event definition changed to
public class TransactionStartedEvent ext
Anton, why do you need to *alter* event sub-system to introduce a new
event? Yakov's issue was that you propagated private interface to public
API, which is bad of course. Come up with a clean design and it will be
accepted.
My problem with TransactionValidator is that it only solves a small probl
Dmitriy,
Yakov is against the solution based on event sub-system
>> I think that we should think about some other solution instead of
altering
>> event sub-system.
Also, I checked is there any chances to fix all the issues found by Yakov
and see that solution becomes overcomplicated in that case.
On Wed, May 23, 2018 at 4:08 AM, Anton Vinogradov wrote:
> Dmitriy, Yakov
>
> Are there any objections to updated design taking into account the comments
> I provided?
>
Anton, I do not like an additional validator. I think you can accomplish
the same with a transaction event. You just need to d
Dmitriy, Yakov
Are there any objections to updated design taking into account the comments
I provided?
пн, 21 мая 2018 г. в 18:49, Anton Vinogradov :
> One more case is to analize and log tx's creators info without tx creation
> restriction.
> This is very important feature on huge system trial
One more case is to analize and log tx's creators info without tx creation
restriction.
This is very important feature on huge system trial period when you may
want to check who creates tx, tx content and configuration.
For example you may want to log stacktrace for any tx without meta or with
empt
Dmitriy,
Main idea is to restrict transaction creation in case label or timeout are
not set.
But there can be variations, for example label should fit some regexp or
timeout should be between 30 and 5000 ms.
That's not easy to restrict this at user code when you have dozens of
libraries written b
Anton,
The change looks very questionable. We cannot be adding configuration
validators for every piece of Ignite API. What is it you are trying to
achieve?
D.
On Mon, May 21, 2018 at 7:22 AM, Anton Vinogradov wrote:
> Yakov, thank's for deep check.
>
> >> I think that we should think about so
Yakov, thank's for deep check.
>> I think that we should think about some other solution instead of
altering
>> event sub-system.
Thank's to your comments now I see that solution is not perfect.
How about to create
interface TransactionsValidator {
boolean validate(IgniteTransactions tx){
Ok, then it probably might have been created before this PR. Anyway, I
would not bother too much about pt 3.
--Yakov
2018-05-21 16:15 GMT+03:00 Dmitry Pavlov :
> Hi Yakov,
>
> I've checked this code and IgniteCacheTestSuite6 includes TxLabelTest, so
> point 3 can be considered as solved.
>
> Sin
Hi Yakov,
I've checked this code and IgniteCacheTestSuite6 includes TxLabelTest, so
point 3 can be considered as solved.
Sincerely,
Dmitriy Pavlov
пн, 21 мая 2018 г. в 16:05, Yakov Zhdanov :
> Anton, I have objections. Please do not merge unless we agree on details.
>
> 1. You use internal API
Anton, I have objections. Please do not merge unless we agree on details.
1. You use internal API in public event, i.e. you cannot have user
accessing to IgniteInternalTx instance through TxEvent.
2. Throwing runtime errors from listener is not documented and I doubt if
it can be fully supported i
Igniters,
Fix is ready.
Code checked by Nikolay Izhikov, all issues fixed
Code benchmarked by Ilya Suntsov, no drop found.
Fix *affects public API*, so I'm proposing everyone interested check it.
Issue: https://issues.apache.org/jira/browse/IGNITE-8446
PR: https://github.com/apache/ignite/pull/40
Anton Vinogradov created IGNITE-8446:
Summary: Ability to check and completely fill transactions on
creation
Key: IGNITE-8446
URL: https://issues.apache.org/jira/browse/IGNITE-8446
Project
>> But I have concern
>> about performance. How can you estimate impact to performance ?
We have to benchmark result.
>> How about to set label name with some useful info if user does not
provide
>> custom name?
You can set custom listener which will do that
>> For example thread name + global
Guys,
Sorry for a dumb question but how the user is expected to use this event?
--
Denis
On Thu, Apr 5, 2018 at 6:06 AM, Anton Vinogradov wrote:
> Igniters,
>
> As far as I know we're working on additional 'label' field for transactions
> [1].
> That's great and will be helpful for customers w
How about to set label name with some useful info if user does not provide
custom name?
For example thread name + global counter?
Thoughts?
--
Alexey Kuznetsov
Hi Igniters,
I also do not see any reasons against this solution. But I have concern
about performance. How can you estimate impact to performance ?
Sincerely,
Dmitriy Pavlov
чт, 5 апр. 2018 г. в 17:20, Nikolay Izhikov :
> +1 from me.
>
> Let's have this events!
>
> I think `EVT_USR_TX_*START*`
+1 from me.
Let's have this events!
I think `EVT_USR_TX_*START*` is more convinient name for it.
As far as we have method `IgniteTransctions#txStart`
В Чт, 05/04/2018 в 16:06 +0300, Anton Vinogradov пишет:
> Igniters,
>
> As far as I know we're working on additional 'label' field for transactio
Igniters,
As far as I know we're working on additional 'label' field for transactions
[1].
That's great and will be helpful for customers with huge deploymens to see
reason of each transaction.
But, since 'label' is optional field, there is no way to guarantee it will
be filled.
I'd like to propo
34 matches
Mail list logo