Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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,

Re: Ability to check and completely fill transactions on creation

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 >

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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, -

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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,

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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.

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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){

Re: Ability to check and completely fill transactions on creation

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:

[jira] [Created] (IGNITE-8446) Ability to check and completely fill transactions on creation

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:

Re: Ability to check and completely fill transactions on creation

>> 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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

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

Re: Ability to check and completely fill transactions on creation

+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

Ability to check and completely fill transactions on creation

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