Menu
▾
▴
#383 Still Getting TXN Exception With Remote Client
We are still getting an org.hibernate.StaleStateException occasionally when we are submitting trims from a remote client. We have changed all of our datasources to xa datasources, but it is still happening. The exception used to occur somewhere in the middle of a set of lab results being submitted. It now occurs only on the first one. If the first one goes they all go. Also If we have more than one set come in at the same time (Labcorp batches their stuff), if the first result of the first set fails, the remaining sets go fine. I can duplicate this by having my development environment remain idle and submittting a set of labs to mirth. It fails. I can then quickly re-submit the set and it will go fine. This happens in production even when the system is not idle for example on 3/23/2009 at 13:02 there was activity, but Labs were submitted and they failed. I am wondering if it is activity within an account? Not all of our accounts are active every day.
I am mailing a zipped up log and the project that submits the labs to John.
One possibility, though remote for this problem:
In PGAdminIII, Index3 on MenuData must look like the following (the index should be on TrimHeader_id, not stringnn):
CREATE INDEX md_index3
ON app.menu_data
USING btree
(trimheader_id);
The provided log has date span: 2008-12-19 -> 2009-02-12
There are three occurrences of org.hibernate.StaleStateException:
* 2008-12-23
* 2009-01-07
* 2009-01-21
The last email I had from Chris Sparrow was 2009-02-17, which was related to slow performance and mirth.
The last email that I have, which deals with transaction errors was 2009-02-06, to which we responded and advised about XA, which I believe was done.
This bug was opened on 2009-03-23, and I don't see how it can report occasional errors with this signature, based on the dates above. According to the dates above, this error signature has not occurred since we last responded in February. It does however seem odd, that there are no entries since 2009-02-12?
Joe
We resolve the performance issues with mirth by pulling the mirth.sar out of jboss and running mirth standalone. Now the performance is great.
I grapped the wrong log file. I will send you a new one. We are experiencing network issues so I can't get to the server right now.
Chris
Please open a new bug if this happens again or you have a new log file.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 360 days (the time period specified by
the administrator of this Tracker).