André Markwalder wrote:
The release we shipped to the customer before had these problems as
well, but not as often as with the new release. Between these two
releases we changed the behaviour of getting the broker and did some
business logic on the server. In the first release we configured the
persistence broker factory to fail if no persistence broker is
available. In the new release we block (whenExhaustedAction=1) until a
new broker is available and retry till we get a new broker and after a
configurable amount of retries we throw an exception. Could it be
possible that this mechanism could trigger the NPE (That the broker will
be closed) ?
If the PBF and commons-pool (used to pool the PB instances) take care of
concurrency there shouldn't be a problem. Currently method
PBF.createPersistenceBroker(PBKey pbKey)
is not synchronized, because it only lookup the pool and commons-pool
use a synchronized method to borrow objects.
We did the above mentionend mechanism because we have some database
queries which takes a bit longer to complete and the connection pool
configured on websphere allows only 10 connections. We have about 200
user on the system and concurrently about 5 user access. That's also the
reason why we mixed the tx declaration of some methods. Typically if we
only read from the database, we don't have to obtain a transactional
context. These methods have the declaration "Not Supported". Other
methods which require a transaction (if we write to the database) have
the declaration "Required". The transaction manager times out after 120
seconds. Some bigger reports take more than 120 seconds to complete. So
we have to speed up these reports or leave the "Not Supported"
declaration in place.
We have an own implementation of the persistence broker. We extend the
PersistenceBrokerImpl and do some additional things in pb.store(),
pb.delete(), pb.retrieveAllReferences() and pb.retrieveReference(). We
had some problems with the proxies configured in the descriptor
repository. We configured our persistence broker in OJB.properties file.
Perhaps something went wrong with the pb or tx handles. Could this own
implementation result in an earlier close of the persistence broker?
Well! Don't ask me ;-)
So you are using PersistenceBrokerFactorySyncImpl with your own PB
implementation. I don't know about the modifications you did, but
normally changes in pb.store(), pb.delete(), pb.retrieveAllReferences()
and pb.retrieveReference() should not affect the behavior of PB.close
method or PoolablePersistenceBroker. Did you modify any of the classes
handling proxy objects?
Is it possible that two users can hold the same persistence broker?
The PB-api is not threadsafe, so sharing of PB instances is not allowed,
each thread have to operate on his own PB instance.
When
user one e.g closes the persistence broker and user two operates on the
closed persistence broker this NPE could happen.
right, I user share a PB instance this could happen. In OJB test-suite
are many multi-threaded tests (plus separate multithreaded session bean
tests) and such a NPE (so far ;-)) never happens.
regards,
Armin
Thanks and best regards
André
Armin Waibel wrote:
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]
---------------------------------------------------------------------
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]
