0026372: Randomly getting the error - ava.lang.Exception: Tx is not active

Notes
(0067013) sjkumar (reporter) 2014-05-08 06:34	Uploading log file (named = openbravo.7z) and screenshot for the usage computation for the issue related to this error. It is coming up in the Compute Usage button.

(0067371) hgbot (developer) 2014-05-22 16:16	Repository: erp/pmods/org.openbravo.contract.services Changeset: 5e40d141660b2d14b79b141c0d808ba146c104a8 Author: Víctor Martínez Romanos <victor.martinez <at> openbravo.com> Date: Thu May 22 16:16:01 2014 +0200 URL: http://code.openbravo.com/erp/pmods/org.openbravo.contract.services/rev/5e40d141660b2d14b79b141c0d808ba146c104a8 [^] Issue 26372: Catch Exception (instead of OBException) to ensure transaction sessions and rollback are properly managed --- M src/org/openbravo/contract/services/process/computation/Computation.java ---

(0067501) sjkumar (reporter) 2014-05-28 00:18 edited on: 2014-05-28 00:24	Issue with different Time Zones in SPM \| Reason for ?Tx is not active? error 1) While displaying a date type column in openbravo/SPM UI at IST timing zone, It is advancing the time stamp by 12 and half hours. For example in database : one of a row in Usage table, has a Usage Starting Date as 05-27-2014 10:11:12. but when I see the same date in SPM UI from IST zone place, It is coming as 05-27-2014 22:41:12 which is 12 and half hours ahead from database showed time stamp value and when we see the same data from Mexico time zone, It is coming as 05-27-2014 12:11:12 which is two hours ahead from the database showed time stamp. Because it stored as 05-01-2014 00:01:00 and validations have been passed. The below is the screenshot of it. See detail attached - Tx Error-TimeZone Bug 18837473 .doc

(0067536) vmromanos (manager) 2014-05-28 16:42	Hi Sanjay, The root cause under the Tx not active is when an EntityPersistenceEventObserver raises an exception in the middle of the computation (not directly related to the timezone issue but with any exception). When an EntityPersistenceEventObserver raises an exception, it automatically deactivate the transaction (Tx), so the computation can't catch the exception and this ugly message about Tx is not active is shown. In this kind of scenarios, the system should be able to catch the exception thrown by the EntityPersistenceEventObserver and log it to the user. We are working on it and we will fix it very soon. On the other hand, the behaviour you're reporting about date and timezone is the expected one. Let me explain how it works: Openbravo stores the dates (day, month, year, hour, minutes, seconds, milliseconds) without timezone information. So if you directly query the database, you will see a date without the timezone information. Instead of storing the timezone information, Openbravo stores all the dates transformed to the server's timezone (Oracle and Tomcat timezone, which must be the same in both); in your case it is probably PST. That means that when you query the database, the dates you see are referenced to PST timezone in your case. Example if you see 12:00 in the database it means 12:00 in PST. When the UI loads a date from the backend, the system automatically transforms it to the client's (web browser) timezone. It means that, if the server and the browser are in different timezones, you will see that the date displayed into the UI is different from the date you can see if you directly query the database. Example if you see 12:00 in the database, which means 12:00 in PST, it may be displayed (for example) at 21:00 in CEST timezone. As a summary: * Dates directly read in database are referenced to the server's timezone * Dates loaded into the UI are automatically transformed by Openbravo from the server's timezone to the client's timezone. * Obviously, if different clients in different timezone see the same date record loaded from the database, they will see it as different dates (with the correspondent offset between the client and server timezone). However, the absolute date (referenced to the common server's timezone) will be the same, and it's the one stored into the database. Important: If you manually load dates into the database (through CSV, using SQL INSERT/UPDATE, or any other way outside of the UI), you must do it always in the server's timezone, to ensure all the dates reference to the same timezone. Right now you're not taking this into account, and it's the reason why you get this problem each time the system updates a subscribed service line (computation process, manual update by the user, etc.). There is a validation run into an EntityPersistenceEventObserver that verifies the subscribed service lines fit into the subscription start date - end date range.

(0067537) hgbot (developer) 2014-05-28 16:47	Repository: erp/pmods/org.openbravo.contract.services Changeset: faa4ad43c4c7292abbd6112596de658d3250669d Author: Víctor Martínez Romanos <victor.martinez <at> openbravo.com> Date: Wed May 28 16:47:42 2014 +0200 URL: http://code.openbravo.com/erp/pmods/org.openbravo.contract.services/rev/faa4ad43c4c7292abbd6112596de658d3250669d [^] Issue 26372: ConsumeExpiredCommitment is able to manage EntityPersistenceEventObserver exceptions Two sessions are opened at the same time: one for the ScrollableResults that contains the IPMs and Contracts Ids, and another one to manage each transaction --- M src-db/database/sourcedata/AD_MESSAGE.xml M src/org/openbravo/contract/services/process/computation/expirecommitment/ConsumeExpiredCommitment.java M src/org/openbravo/contract/services/process/computation/expirecommitment/ConsumeExpiredCommitmentDao.java ---

(0067612) hgbot (developer) 2014-05-30 11:41	Repository: erp/pmods/org.openbravo.contract.services Changeset: c83660a340db9f837c369fb07a2784153ebe9855 Author: Naiara Martinez <naiara.martinez <at> openbravo.com> Date: Thu May 29 12:10:25 2014 +0200 URL: http://code.openbravo.com/erp/pmods/org.openbravo.contract.services/rev/c83660a340db9f837c369fb07a2784153ebe9855 [^] Fixed issue 26372: Fix tx is not active --- M src/org/openbravo/contract/services/process/computation/Computation.java M src/org/openbravo/contract/services/process/computation/ComputationDao.java ---

Issue History
Date Modified	Username	Field	Change
2014-04-25 06:26	sjkumar	New Issue
2014-04-25 06:26	sjkumar	Assigned To	=> vmromanos
2014-04-25 06:26	sjkumar	File Added: Tx_error.log
2014-05-08 06:34	sjkumar	Note Added: 0067013
2014-05-08 06:34	sjkumar	File Added: openbravo.7z
2014-05-22 16:16	hgbot	Checkin
2014-05-22 16:16	hgbot	Note Added: 0067371
2014-05-28 00:18	sjkumar	Note Added: 0067501
2014-05-28 00:18	sjkumar	Note Edited: 0067501	View Revisions
2014-05-28 00:24	sjkumar	File Added: Tx Error-TimeZone Bug 18837473 .doc
2014-05-28 00:24	sjkumar	Note Edited: 0067501	View Revisions
2014-05-28 14:03	vmromanos	Status	new => scheduled
2014-05-28 14:03	vmromanos	fix_in_branch	=> pi
2014-05-28 16:42	vmromanos	Note Added: 0067536
2014-05-28 16:47	hgbot	Checkin
2014-05-28 16:47	hgbot	Note Added: 0067537
2014-05-30 11:41	hgbot	Checkin
2014-05-30 11:41	hgbot	Note Added: 0067612
2014-05-30 11:41	hgbot	Status	scheduled => resolved
2014-05-30 11:41	hgbot	Resolution	open => fixed
2014-05-30 11:41	hgbot	Fixed in SCM revision	=> http://code.openbravo.com/erp/pmods/org.openbravo.contract.services/rev/c83660a340db9f837c369fb07a2784153ebe9855 [^]
2014-05-30 12:17	vmromanos	Review Assigned To	=> vmromanos
2014-05-30 12:17	vmromanos	Status	resolved => closed

Relationships [ Relation Graph ] [ Dependency Graph ]