I have to reproduce the error first and fix the issue otherwise our
customer would be "a bit" angry about us ;-( . At the moment they have
to reboot the server every time the error occurs.
Afterwards I will get the newest version and will run it against the
testsuite, that's no question. If we can contribute something to OJB we
will do that of course.
Best regards
André
Armin Waibel wrote:
André Markwalder wrote:
Thanks for the suggestions ;-)
We test the server with a massive multithreaded test but only on one
machine. You're right we should test the server on multiple clients.
I will do this.
Thanks for your help. We try to reproduce the error in our
environment. I will let you know if we find something concerning OJB.
ok! Think this issue is important for other OJB user too.
One last question. When will OJB 1.0.4 be available?
I know a new release is overdue, but there is a nasty bug (OJB-63)
which should be fixed before next release (Jakob is working on this
stuff).
Except for OJB-63 and some documentation updates 1.0.4 is ready for
release.
If possible please get the latest version from CVS (OJB_1_0_RELEASE
branch) and run it against your test-suite (to check the refactored PB
handling in managed environments).
regards,
Armin
Best regards
André
Armin Waibel wrote:
André Markwalder wrote:
I tried it with an eviction thread enabled same result, everything
works fine on our installation. I changed some settings on our
websphere and try it again.
How do you test your installation - running a massive multithreaded
test? I recommend to write such a test (and if possible to run
physical different clients against the server)
Did you have a look at the code I posted in an earlier mail? Did
you see something special how we obtain the broker in the beans?
Seems ok.
Only minor suggestions.
public static AesPersistenceBrokerFactory getInstance()
the well known singleton problem, it's not guaranteed that only one
AesPersistenceBrokerFactory will be created on startup (thus it
could happen that OJB's PBF is instantiated twice too). But this
shouldn't be a problem (in OJB we use this "wrong" singleton pattern
too).
private PersistenceBroker getBroker(int retry)
Before returning the PB instance all listeners will be removed and
then new temporary listener are added. It's not recommended to
remove all listener (permanent and temporary) when lookup a new PB
instance, because OJB add some listener too (e.g. the caching
implementations) and this call will remove these listener instances.
I know in 1.0.3 is a bug caused by the RsIterator class which
increase the temporary listener (on each query execution) while
using the PB instance (fixed in upcoming 1.0.4), but OJB remove all
temporary listener by itself on PB.close() call.
regards,
Armin
I attached the code again after this email.
Thanks a lot and best regards
André
Every bean method gets the broker in the following manner:
PersistenceBroker broker = null;
try {
// get broker
broker = getBroker();
// ... processing
// here we instantiate new classes which uses the broker
// we pass the broker via the constructor to the class
}
catch (....Exception e) {
// AesTransactionException is a RuntimeException so the
database actions will be rolled back
throw new AesTransactioinException(....);
}
finally {
releaseBroker(broker);
}
getBroker():
AesPersistenceBrokerFactory.getInstance().getBroker()
releaseBroker();
AesPersistenceBrokerFactory.getInstance().releaseBroker(broker);
AesPersistenceBrokerFactory (Singleton implementation based on a
unique app name at the moment it's only one app accessing the beans):
public static AesPersistenceBrokerFactory getInstance() {
String appName =
AesServerProperties.getInstance().getProperty(AesServerProperties.PROP_AES_APPLICATION);
AesPersistenceBrokerFactory instance =
(AesPersistenceBrokerFactory)instances.get(appName);
if (instance==null) {
instance = new AesPersistenceBrokerFactory();
instances.put(appName,instance);
}
return instance;
}
public PersistenceBroker getBroker() {
return getBroker(0);
}
private PersistenceBroker getBroker(int retry) {
PersistenceBroker broker = null;
try {
if (retry > 0) {
log.warn("Tried to retrieve broker more than once ("
+ retry + "). Increase connection pool max size and OJB maxActive
settings.");
}
// here the call will be blocked till timeout
broker = pbf.defaultPersistenceBroker();
} catch (PBFactoryException e) {
if (retry < retryAttempts) {
return getBroker(retry+1);
}
throw new AesTransactionException(new
AesOjbPBNotAvailableException("No more Persistence Broker are
available ..."),this.getClass());
}
broker.removeAllListeners();
broker.addListener(new AesPBLifeCycleListener());
broker.addListener(new AesPBStateListener());
return broker;
}
public void releaseBroker(PersistenceBroker broker) {
if (broker != null) {
broker.close();
}
broker = null;
}
Armin Waibel wrote:
André Markwalder wrote:
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.
It's correct (each PB instance use 0 or 1 connection instance, so
the connection-pool should never exhaust because OJB doesn't use
more than 50 broker instances).
This is really interesting in the commons-pool bug report the
reporter mentioned the problem (of negative active objects) was
caused by the eviction thread, but your customer have the same
problem without using this feature.
regards,
Armin
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]
---------------------------------------------------------------------
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]
