My code do lots of selects, updates, merges, etc. How i can undestand what I need to call commit?It is a very big question :). It is really depends on your application, but basically you have two options:
Maybe exist some method to get count or size of modified, inserted, or deleted records in current transaction? Also we must count calss like SELECT .. FOR UPDATE;I am afraid that TimesTen doesn't contain this functionality. Your application should commit transaction when it's necessary based on business logic.
I Write timesten application using C api.Commit calls delineate transactions (atomic units of work in the database). The concept of what constitutes a transaction is fundamentally and intrinsically determined by the application and its logic. Only the application developer can decide what should constitute a transaction and hence when to call commit. No other metric or guideline makes any sense. You need to consider what kinds of data manipulation your application performs and which operations need to be grouped together and performed atomically. Commit (or rollback) release locks so SELECT operations that acquire locks (such as SELECT FOR UPDATE) should alose be considered when planning your transaction boundaries.
My code do lots of selects, updates, merges, etc. How i can undestand what I need to call commit?
It is a very bad idea to let the user decide when to commit (sorry Gennady!). User's can go for a coffee, go home in the evening etc. and can leave open and hence long running transactions.I think it is a very good topic for debates.
In any real-world OLTP system, the application is executing pre-defined logic based on carefully modelled business processes which have then been translated into application code, database transactions etc.Absolutely agree.
Part of that design and implementation should (indeed must)- include very precise definitions of what constitutes a business transaction and how that maps to one or more database transactions.Also agree.
There is no scope for end users to arbitrarily make those decisions; indeed that will result in inconsistent/invalid data.I've got some questions.
There are very few cases where an end user should directly be allowed to decide when to commit or rollback.Basically, In most of the application i've seen the end user has only these two options :) Do you think that it's not OLTP system? I think it is.
Sure they can be given an 'Apply' or 'Cancel' option within the application but that is not the same thing at all.
Also, good application design should ensure that the application never keeps a database transaction open while waiting for user input/decision.I agree with you, but how achieve concurrency without using transaction? What if different people are changing the same records?
I have seen many production issues caused by that kind of design (and I am speaking generally here not just about TimesTen).