We changed only the settings for maxActive to 50 (not 100) and
whenExhaustedAction to 1 (not 0). Attached the section about the
PersistenceBroker pool configuration in OJB.properties file.
I think we have at the moment 50 db connections configured in the
connection pool from websphere. We changed the maxActive settings
according to this.
Is this wrong? I read somewhere that the maxActive settings have to be
greater or equal to the db connections in the connection pool.
regards
André
#----------------------------------------------------------------------------------------
# PersistenceBroker pool
#----------------------------------------------------------------------------------------
# PersistenceBroker pool configuration
# This pool uses the jakarta-commons-pool api.
# There you can find things described in detail.
#
# maximum number of brokers that can be borrowed from the
# pool at one time. When non-positive, there is no limit.
maxActive=50
#
# controls the maximum number of brokers that can sit idle in the
# pool (per key) at any time. When non-positive, there is no limit
maxIdle=-1
#
# max time block to get broker instance from pool, after that exception
is thrown.
# When non-positive, block till last judgement
maxWait=2000
#
# indicates how long the eviction thread should sleep before "runs" of
examining
# idle objects. When non-positive, no eviction thread will be launched.
timeBetweenEvictionRunsMillis=-1
#
# specifies the minimum amount of time that an broker may sit idle
# in the pool before it is eligable for eviction due to idle time.
# When non-positive, no object will be dropped from the pool due
# to idle time alone (depends on timeBetweenEvictionRunsMillis > 0)
minEvictableIdleTimeMillis=1000000
#
# specifies the behaviour of the pool when broker capacity is
# exhausted (see maxActive above)
# 0 - fail
# 1 - block
# 2 - grow
whenExhaustedAction=1
Armin Waibel wrote:
André Markwalder wrote:
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?
Normally never. The active persistence brokers count is direct read
from the used commons-pool instance. Seems this problem was already
reported for commons-pool
http://issues.apache.org/bugzilla/show_bug.cgi?id=35617
I don't know if this bug could cause more side-effects, e.g. returning
the same instance twice.
Did you modify the settings of section "PersistenceBroker pool" in
OJB.properties file (except the 'whenExhaustedAction' property), e.g.
enable the eviction thread "timeBetweenEvictionRunsMillis"?
regards,
Armin
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]
---------------------------------------------------------------------
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]
