[JBoss JIRA] (JBTM-2280) alternative to JNDI
by Gavin King (JIRA)
[ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.... ]
Gavin King updated JBTM-2280:
-----------------------------
Description:
So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources.
Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI.
IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all.
XADataSource xads = youJustDontNeedToCare();
DataSource ds = narayana.registerDataSource(xads);
Or something like that. Of course I'm sure I'm missing some subtleties here.
was:
So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources.
Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a total distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI.
IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't case where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all.
XADataSource xads = youJustDontNeedToCare();
DataSource ds = narayana.registerDataSource(xads);
Or something like that. Of course I'm sure I'm missing some subtleties here.
> alternative to JNDI
> -------------------
>
> Key: JBTM-2280
> URL: https://issues.jboss.org/browse/JBTM-2280
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Reporter: Gavin King
> Assignee: Tom Jenkinson
>
> So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources.
> Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI.
> IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all.
> XADataSource xads = youJustDontNeedToCare();
> DataSource ds = narayana.registerDataSource(xads);
> Or something like that. Of course I'm sure I'm missing some subtleties here.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2280) alternative to JNDI
by Gavin King (JIRA)
Gavin King created JBTM-2280:
--------------------------------
Summary: alternative to JNDI
Key: JBTM-2280
URL: https://issues.jboss.org/browse/JBTM-2280
Project: JBoss Transaction Manager
Issue Type: Feature Request
Reporter: Gavin King
Assignee: Tom Jenkinson
So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources.
Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a total distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI.
IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't case where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all.
XADataSource xads = youJustDontNeedToCare();
DataSource ds = narayana.registerDataSource(xads);
Or something like that. Of course I'm sure I'm missing some subtleties here.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2274) Create separate assumed complete type for heuristic transactions
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2274?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-2274:
---------------------------------------
I have already merged pull request for 4.17. Now waiting for the CI nodes to get back online to retest master.
> Create separate assumed complete type for heuristic transactions
> ----------------------------------------------------------------
>
> Key: JBTM-2274
> URL: https://issues.jboss.org/browse/JBTM-2274
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 4.17.24, 5.0.4
>
>
> Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the log record after the move.
> Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2259:
-----------------------------------
Fix Version/s: 6.0.0
(was: 5.0.4)
Moving out to 6 since there is a workaround:
"WildFly disables the delistResource calls in beforeCompletion, and IronJacamar kills the ManagedConnection if it detects a problem in afterCompletion."
We should push for ordering semantics in the next revision of the JTA spec:
There is a discussion in the comments to https://java.net/jira/browse/JTA_SPEC-4 and there are also some comments in JTA_SPEC-11
> Allow the ordering of some synchronizations to be configurable
> ---------------------------------------------------------------
>
> Key: JBTM-2259
> URL: https://issues.jboss.org/browse/JBTM-2259
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 6.0.0
>
>
> IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA).
> The request is to add a configuration option to control the order in which certain synchronizations are called.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2279) Provide a way to allow the override a set CheckedActionFactory
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2279:
-----------------------------------
Summary: Provide a way to allow the override a set CheckedActionFactory
Key: JBTM-2279
URL: https://issues.jboss.org/browse/JBTM-2279
Project: JBoss Transaction Manager
Issue Type: Enhancement
Components: Transaction Core
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Fix For: 5.0.4
Out of the box the BasicAction caches the reference to the checkedactionfactory and so if a users classpath is not available to narayana there is no way for a user to provide a CAF to Narayana.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2264:
--------------------------------
Fix Version/s: 5.0.4
> Error enlisting second xa resource on the same oracle instance but other schema
> -------------------------------------------------------------------------------
>
> Key: JBTM-2264
> URL: https://issues.jboss.org/browse/JBTM-2264
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Evgeniy Smelik
> Assignee: Tom Jenkinson
> Fix For: 5.0.4
>
> Attachments: sscce.zip, sscce.zip, test.log
>
>
> I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema.
> Whole stack trace:
> {noformat}
> oracle.jdbc.xa.OracleXAException
> at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110)
> at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> {noformat}
> (Detail log and SSCCE are attached).
> I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances.
> I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not.
> I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-...].
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2278) Allow the transaction manager suspend operation to succeed for JTS mode
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2278?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2278:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/752
> Allow the transaction manager suspend operation to succeed for JTS mode
> -----------------------------------------------------------------------
>
> Key: JBTM-2278
> URL: https://issues.jboss.org/browse/JBTM-2278
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTS
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.0.4
>
>
> It is not possible to perform TransactionManager::suspend operation during an afterCompletion call when the server is configured for JTS and has JacORB configured with interposition interceptors. This is because the transaction has not been used on the thread yet and when OTSManager.current() operation finds the PropagationContext in PICurrent to tries to recreate the hierarchy and ArjunaTransactionImple register_resource detects the transaction is no longer active so throws an Inactive exception causing suspend to fail.
> SystemException is a valid response code from suspend but it would be desirable to try to avoid this when the transaction is local to the Synchronization.
> Allowing suspend means this code would work:
> public afterCompletion(status) {
> tm.suspend()
> tm.begin()
> tm.commit()
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months