[JBoss JIRA] Created: (JBTM-536) JTS compilation with IBM jdk1.5 fails due to "Fatal Error: Unable to find package java.lang"
by Ivo Studensky (JIRA)
JTS compilation with IBM jdk1.5 fails due to "Fatal Error: Unable to find package java.lang"
--------------------------------------------------------------------------------------------
Key: JBTM-536
URL: https://jira.jboss.org/jira/browse/JBTM-536
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JTS
Environment: IBM JDK 1.5, Apache Ant 1.6.5, Linux
Reporter: Ivo Studensky
Fix For: 4.6.1
Compiler cannot find java.lang package in case of compiling with IBM JDK 1.5.
See the snippet of compilation output:
...
[java] com.hp.mwlabs.orbportability.orbspecific.jacorb.compile:
[java] [echo] Performing JacORB IDL compile
[java] [classpath-builder] Property 'build.jacorb.classpath' set to classpath ...
[java] [echo] Performing JacORB orb specific compile
[java] [javac] Compiling 11 source files to /mnt/hudson_workspace/workspace/jbossts-testsuite-matrix/jdk/ibm15/label/RHEL4_x86/trunk/ArjunaJTS/orbportability/orbspecific-build
[java] [javac] Fatal Error: Unable to find package java.lang in classpath or bootclasspath
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (JBTM-575) javax.transaction.RollbackException root cause
by Richard Kennard (JIRA)
javax.transaction.RollbackException root cause
----------------------------------------------
Key: JBTM-575
URL: https://jira.jboss.org/jira/browse/JBTM-575
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: JBoss 5.1.0.GA
Reporter: Richard Kennard
In JBoss 4.2.3.GA and previous releases, when a transaction rolled back the RollbackException included the root cause of the exception. This enhancement was implemented in response to JBAS-4238 and JBTM-66.
However, in JBoss 5.1.0.GA this enhancement has been lost in some scenarios. This does not affect manual debugging (the root cause is still logged higher up in the logs), but makes it difficult for application code that relies on being able to unwrap the RollbackException to determine its root cause and therefore take appropriate action.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBTM-619) Cannot enlist two Oracle XAConnection resources in one transaction
by Wade Poziombka (JIRA)
Cannot enlist two Oracle XAConnection resources in one transaction
------------------------------------------------------------------
Key: JBTM-619
URL: https://jira.jboss.org/jira/browse/JBTM-619
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JTA
Affects Versions: 4.7.0
Environment: Windows and Linux.
Reporter: Wade Poziombka
An attempt to enlist two Oracle connections causes the second enlistResource to fail with an exception similar to:
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:938)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:244)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:902)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:513)
Note the line number changes a bit depending on version of Oracle JDBC etc. However, the affect is always the same.
There are others who noted this problem on the forum with no resolution or reply (except my own concurring with the observation).
In particular two connections to same server using different user id's and passwords. I will test whether two completely separate oracle instances have this issue and update the bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBTM-443) check LastResource logging and recovery
by Jonathan Halliday (JIRA)
check LastResource logging and recovery
---------------------------------------
Key: JBTM-443
URL: https://jira.jboss.org/jira/browse/JBTM-443
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JTA Implementation, JTS Implementation, Recovery
Affects Versions: 4.4.0.GA
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.6
Where transactions contain LastResource, they may not be fully recoverable. Check if LastResource records are written to the log and if so, what happens to them during recovery.
Optimise the case where a tx contains multiple last resources, as we need to write a log for such a tx only if it also contains real resources. The case where the tx only has a single resource enlisted is irrelevant as the onePhaseCommit optimization already skips logging.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBTM-599) Synchronization problem in CacheStore
by Andrew Dinn (JIRA)
Synchronization problem in CacheStore
-------------------------------------
Key: JBTM-599
URL: https://jira.jboss.org/jira/browse/JBTM-599
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Andrew Dinn
This bug manifests occasionally when running the CachedTest. The AsyncStore thread suspends inside its run method on a (120 sec) timed wait because the cache is not full. When I managed to catch this case in the debugger I found that there were many writer threads (~30) suspended inside addWork in an untimed wait on the overflow lock. So, these writing threads make no progress for 120 seconds. The AsyncStore thread does notify the object on which the writers are waiting but there is clearly a window where the writers can go to sleep while the cache is full and not get notified when the AsyncStore thread has emptied it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months