I probably would agree with the point about commit/rollback methods, but others look useful for me. You're starting a DB transaction and may need to know details about ongoing cache transaction. E.g., what if you want to start DB transaction with the same isolation? Meta can also contain some useful data that is set outside of store and is needed for dealing with DB, and so on.
-- Val On Mon, Mar 23, 2015 at 2:22 AM, Vladimir Ozerov <[email protected]> wrote: > Hi, > > I'm trying to understand why CacheStoreSession.transaction() method exists. > There are 3 group of methods we have on Transaction API: > 1) Methods changing TX state (commit(), rollback(), etc.); > 2) Meta-related methods (addMeta(), etc.). > 3) Read-only methods with TX info (concurrency/isolation, start time, > thread ID, etc.); > > Are there any use cases when we expect user to use any of these methods > when reading/writing from/to store? > > IMHO, user will never commit TX in this place, rollback() is achieveable > with exception throwing, meta-methods are already targeted for removal from > public API, and read-only methods are simply have no practical use-cases. > > Moreover, exposing commit/rollback/setRollbackOnly methods to user during > write operations is dangerous and will yield in unexpected behavior because > they are called from GridCacheMapEntry.innerX() methods. > > Am I missing something? > > Vladimir. >
