Hi Armin,
Sorry for the disturbance again. I saw in our log files from the
customer that active persistence brokers is negative (-1). How could
that happen?
Thanks and best regards
André
Armin Waibel wrote:
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]
--
André Markwalder
Software Architect
alabus ag
Graben 5
CH-6300 Zug
Phone: +41 (0)41 729 88 77
Fax: +41 (0)41 729 88 78
Mail: [EMAIL PROTECTED]
www: www.alabus.com
alabus ag beschäftigt Business- und Technologieexperten in den Kernbereichen
CRM, ERM und Business Integration. alabus legt den Fokus auf
business-orientierte IT-Lösungen, die unternehmensintern neue Standards setzen.
Zu unseren Kunden gehören zukunftsgestaltende Unternehmen aus der Schweiz mit
internationaler Ausrichtung.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
