Agree with Andrey here. Probably, we can keep existing JCache metrics for implicit transactions, but we should design a whole new interface to handle transaction metrics, including various transaction stages, such as lock acquisition, prepare and commit phases. In my opinion, this is the only way to have unambiguous metrics in the product.
2017-09-20 17:58 GMT+03:00 Andrey Gura <ag...@apache.org>: > Slava and Igniters, > > Do you have any suggestions about described problem? > > From my point of view JCache API metrics specification has a number of > statements that can't be uniquely treated by Ignite user because of > implementations details. Most obvious problems here are related with > transactions that are distributed and have some properties that affect > their behaviour. Pessimistic transactions during entry modification > will enlist entry into transaction (read operation), acquire lock (it > can take some time if another transaction is already lock owner) and > eventually write modified entry into the cache. Where is modification > operation start? What if after cache.put() and before commit user > performs some time consuming operation? For optimistic transactions > still there is lock waiting time that affects metrics. > > So JCache API metrics are useless for transactions and could confuse > user. It seems that we shouldn't support JCache metrics at all in case > of transactional operations. May be we can offer another metrics that > could be more useful. > > Thoughts? > > On Tue, Sep 19, 2017 at 8:19 PM, Вячеслав Коптилин > <slava.kopti...@gmail.com> wrote: > > I'd want to make a new attempt to discuss JCache metrics, especially > > time-based metrics. > > As discussed earlier ( > > http://apache-ignite-developers.2346864.n4.nabble. > com/Cache-Metrics-tt19699.html > > ), > > there are two approaches (and at first glance, the second one is > > preferable): > > #1 Node that starts some operation is responsible for updating the > > cache metrics. > > #2 Primary node (node that actually executes a request) > > > > I have one question/concern about time-based metrics for transactional > > caches. > > The JCache specification does not have definition like a transaction, > > partitioned cache etc, > > and, therefore, cannot provide convenience and clear understanding about > > the average time for that case. > > > > Let's assume, for example, we have the following code: > > > > try (Transaction tx = > > transactions.txStart(TransactionConcurrency.OPTIMISTIC, > > TransactionIsolation.READ_COMMITTED)) { > > value = cache.get(key); > > // calculate new value for the given key > > ... > > cache.put(key, new_value); // (1) > > > > // some additional operations > > > > // another update > > value = cache.get(key); // (2) > > ... > > cache.put(key, new_value); > > > > tx.commit(); // (3) > > } > > > > What is the average time for write operation? Is it a time needed for > > enlisting an entry in the transaction scope, acquiring locks, committing > > changes? > > For that particular case, current implementation accumulates both timings > > (1)&(2) on the local node during performing put operation, but 'write' > > counter is updated only once on data node during commit phase. > > I think this behavior is not obvious at least. > > > > Thanks, > > Slava. >
