Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0026372 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [Modules] Service Contract Management | major | random | 2014-04-25 06:26 | 2014-05-30 12:17 | |||
Reporter | sjkumar | View Status | public | |||||
Assigned To | vmromanos | |||||||
Priority | high | Resolution | fixed | Fixed in Version | ||||
Status | closed | Fix in branch | pi | Fixed in SCM revision | c83660a340db | |||
Projection | none | ETA | none | Target Version | ||||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Regression date | ||||||||
Regression introduced by commit | ||||||||
Regression level | ||||||||
Review Assigned To | vmromanos | |||||||
Regression introduced in release | ||||||||
Summary | 0026372: Randomly getting the error - ava.lang.Exception: Tx is not active | |||||||
Description | Getting this error randomly. Not sure what is causing this. Notice that mostly this comes whenever some process needs to be run to process the data. I have seen this error message coming when doing the following - Click on the Compute usage button on the service contract window - Submitting the subscription main billing process | |||||||
Steps To Reproduce | I cannot produce this all the time. It comes and goes. I am attaching the log from the $CATALINA_HOME/logs/Openbravo.log. See these logs from the bottom up. | |||||||
Tags | No tags attached. | |||||||
Attached Files | Tx_error.log [^] (45,414 bytes) 2014-04-25 06:26 openbravo.7z [^] (143,288 bytes) 2014-05-08 06:34 Tx Error-TimeZone Bug 18837473 .doc [^] (427,520 bytes) 2014-05-28 00:24 | |||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |
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 |
Copyright © 2000 - 2009 MantisBT Group |