Hi Andrè,
André Markwalder wrote:
Hi Armin,
You wrote in the answer for Colin that always a running (JTA)tx is
expected. Does that mean, when we use OJB in a managed environment (e.g.
WebSphere) and use declarative tx, the declaration of "Not Supported" on
method level or even on bean level is not allowed when we use OJB (We
use OJB 1.0.3)?
I must admit that (currently) we don't have a test-case to check OJB's
behavior when using "Not Supported" tx-demarcation. In upcoming 1.0.4 a
minor refactoring was done (regarding the PB behavior when OJB can't
find a running JTA-tx).
We experienced NullPointerExceptions on pb.getClassDescriptor()
(DescriptorRepository is null on the pb). I had a look at the source
code and saw that this only happens when the broker has been closed
(Sets DescriptorRepository to null).
yep, such a NPE should never happen. It could only happen when you
operate on a closed PB instance (a PB instance already returned to
PB-pool), when lookup a PB instance from the pool, the current used
DescriptorRepository instance will be set by the pool.
We have a mix of tx declaration
(Bean tx: Required, some methods: Not Supported). I saw also that the
broker is closed when a transaction is finished. We always close the
brokers after we used it (try/finally block).
The PB.close() call at the end of each session bean method is
recommended, because this will close the current used PB handle (a
wrapper class around the real poolable PB instance), the real PB
instance is only closed when OJB isn't run within an active JTA-tx, else
the PB instance is closed on tx end.
Is it possible that the
mix of tx declarations can cause the NPE on pb.getClassDescriptor()?
Maybe.... sorry, I never got such a NPE. Could you change the
declarative tx demarcation to "required" and run the tests again
(without mixed tx) - what happen to the NPE?
regards,
Armin
Regards
André
Armin Waibel wrote:
Hi Colin,
> What I want to do is have just a _single_ module using the XA PB for
it's
> transactional operations, while the rest use the default PB.
However when I
> set my project up as above I get errors whenever I use _any_ broker
to do
> non-JTA transaction demarcation:
>
It's not recommended to mix tx demarcation strategies (OJB's PB-tx and
the JTA-api of the appServer).
In managed environments OJB expect that all transaction demarcation is
delegated to the JTA-api. Thus you always have to use the JTA-api
(with both datasources defined in repository file), either via
declarative tx (in the descriptor of your session bean) or
programmatic tx (lookup UserTransaction).
The only problem with OJB 1.0.3 is that in managed environment always
a running (JTA)tx is expected. Thus you need for all operations JTA
tx-demarcation.
We try fix this in upcoming 1.0.4 (CVS OJB_1_0_RELEASE branch) by
differentiate between managed session (when a JTA-tx is active) and
non-managed session (no JTA-tx)
(In 1.0.4 it's not allowed to use ConnectionFactoryManagedImpl when
performing queries without tx-demarcation).
regards,
Armin
Colin O'Toole wrote:
Hi there,
I am using OJB in a j2ee app running on weblogic. There is one
section of
the code that needs to be part of a JTA transaction (database access
via the
PB API and also some JMS writes).
I have the following:
1. In OJB.properties:
-
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFa
ctorySyncImpl
-
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryMa
nagedImpl
-
JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WeblogicTran
sactionManagerFactory
2. In Weblogic:
- One XA datasource
- One non-XA datasource
3. In repository_database.xml
- Two <jdbc-connection-descriptor>s, one pointing at the XA
datasource, the
other pointing at the non-XA datasource
<!-- this connection is used as the default by OJB -->
<jdbc-connection-descriptor
jcd-alias="DataSource"
default-connection="true"
platform="Oracle"
jdbc-level="2.0"
eager-release="false"
batch-mode="false"
useAutoCommit="0"
ignoreAutoCommitExceptions="true"
jndi-datasource-name="java:comp/env/myDataSource"
>
<sequence-manager
className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
<attribute attribute-name="autoNaming"
attribute-value="true"/>
</sequence-manager>
</jdbc-connection-descriptor>
<!-- This connection uses the XA data source -->
<jdbc-connection-descriptor
jcd-alias="XADataSource"
default-connection="false"
platform="Oracle"
jdbc-level="2.0"
eager-release="false"
batch-mode="false"
useAutoCommit="0"
ignoreAutoCommitExceptions="true"
jndi-datasource-name="java:comp/env/myXADataSource"
>
<sequence-manager
className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
<attribute attribute-name="autoNaming"
attribute-value="true"/>
</sequence-manager>
</jdbc-connection-descriptor>
What I want to do is have just a _single_ module using the XA PB for
it's
transactional operations, while the rest use the default PB. However
when I
set my project up as above I get errors whenever I use _any_ broker
to do
non-JTA transaction demarcation:
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker()
broker.beginTransaction();
broker.store(obj);
broker.commitTransaction();
Results in: java.lang.UnsupportedOperationException: In managed
environments
only JTA transaction demarcation allowed
Can anyone tell me if it's possible to do what I want, Or am I
approaching
this from the wrong angle entirely? I've failed to find anything
detailed
about OJB with JTA, so any help would be great.
Thanks,
Colin.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
