You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Gary <gl...@yahoo.com> on 2004/06/15 21:25:16 UTC
New Warnings in Managed Environment with RC7
I am now getting the following warnings in a JTA
environment (this worked fine, no messages, before
RC7):
2004-06-15 13:32:26,728 WARN
[Servlet.Engine.Transports : 0] No running tx found,
please only delete objects in context of an
PB-transaction, to avoid side-effects - e.g. when
rollback of complex objects
(org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java))
Looking into the code, it appears as though I am now
required to do a pb.beginTransaction() in even a
managed environment. Am I missing something?
Thanks for all your hard work, Gary
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Question on update processing
Posted by Armin Waibel <ar...@apache.org>.
Hi Raghavan,
Kollivakkam R. Raghavan wrote:
> When we store data into a database using OJB, in order to solve the
> concurrent change issue we're created a col called mod_num (integer)
> which we are setting up to auto increment on each update to that row.
> The idea is to not allow a change to happen if the mod_num in the db
> does not match the value in the data object (i.e. someone else has
> updated the record).
>
> 2 questions:
> 1. Is this the best way to do this?
> 2. If this is acceptable (I've seen other commercial software use this
> mechanism), then what's the best way to setup OJB to help me without
> everyone having to worry about this logic
this sounds like optimistic locking. Please have a look at
http://db.apache.org/ojb/docu/faq.html#optimisticLocking
regards,
Armin
>
> Thanks
> Raghavan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Question on update processing
Posted by "Kollivakkam R. Raghavan" <rk...@cisco.com>.
When we store data into a database using OJB, in order to solve the
concurrent change issue we're created a col called mod_num (integer)
which we are setting up to auto increment on each update to that row.
The idea is to not allow a change to happen if the mod_num in the db
does not match the value in the data object (i.e. someone else has
updated the record).
2 questions:
1. Is this the best way to do this?
2. If this is acceptable (I've seen other commercial software use this
mechanism), then what's the best way to setup OJB to help me without
everyone having to worry about this logic
Thanks
Raghavan
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: New Warnings in Managed Environment with RC7
Posted by Armin Waibel <ar...@apache.org>.
Hi Gary,
Gary wrote:
> Armin:
>
> Thanks again for your help.
>
> Do you mean that I should close the PB before the
> commit is called?
yep!
> If so, I tried it, with the same
> results.
>
> I am still confused as to what the correct ordering of
> PB opens/closes and commit/rollback operations are.
>
> This all worked great before I moved to RC7. I can't
> remember if I was on RC5 or RC6 before...
>
we changed the internal connection handling between rc6 and rc7, because
JBoss always warn about unclosed connections in JTA tx, thus we close
the used connection handle on PB.close() call on the PB handle instance,
but keep internal the real used PB instance.
The PB.close() call have to be invoked before the tx commits. This means
if container managed/declarative tx is used before the method quit, if
bean managed/programmatically tx is used before the
UserTransaction.commit() was called.
On the commit of the JTA transaction OJB was notified by the tx to do
the real cleanup and close of the real used PB instance.
regards,
Armin
> Gary
>
> --- Armin Waibel <ar...@apache.org> wrote:
>
>>Hi Gary,
>>
>>Gary wrote:
>>
>>
>>>No, I first commit or rollback the transaction,
>>
>>and
>>
>>>then close the PB.
>>>
>>
>>ok, so I think this is the reason for the failure.
>>In managed
>>environments the PB instance has the same behavior
>>as a DataSource in
>>managed environments. Means that you operate with an
>>PB handle instance
>>(wraps the real PB instance) and after use you have
>>to close the handle
>>instance. If you use an connection from a DataSource
>>in an managed
>>environment you have to close the connection before
>>the tx was completed
>>too (I think so).
>>
>>Maybe it will be better only to log an warning
>>instead of throwing an
>>exception in this case.
>>
>>regards,
>>Armin
>>
>>
>>>Gary
>>>
>>>--- Armin Waibel <ar...@apache.org> wrote:
>>>
>>>
>>>>Gary wrote:
>>>>
>>>>
>>>>
>>>>>Armin:
>>>>>
>>>>>Thanks for the quick reply. Do you guys have a
>>>>>"contribute" site like SourceForge so I could buy
>>>>
>>>>you
>>>>
>>>>
>>>>>a beer?
>>>>>
>>>>
>>>>Think I should avoid to drink alcohol, because
>>
>>your
>>
>>>>problem seems really
>>>>sophisticated ;-)
>>>>
>>>>
>>>>
>>>>
>>>>>No, I wasn't using the "Sync" factory. When I
>>>>
>>>>change
>>>>
>>>>
>>>>>to it, I get a new error:
>>>>>2004-06-15 15:19:29,798 ERROR [TCP
>>>>>Connection(7)-172.24.54.129] Connection is in
>>>>
>>>>local
>>>>
>>>>
>>>>>transaction, do a 'localCommit' or
>>
>>'localRollback'
>>
>>>>>beforeperform the connection release - rollback
>>>>
>>>>the
>>>>
>>>>
>>>>>connection now
>>>>>
>>>>
> (org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java))
>
>>>>hmm, do you close the PB instance within the used
>>>>method or before the
>>>>tx demarcation ends?
>>>>I assume you don't.
>>>>
>>>>regards,
>>>>Armin
>>>>
>>>>
>>>>
>>>>
>>>>>It has the following stack trace:
>>>>>System Thread [TCP Connection(7)-172.24.54.129]
>>>>>(Suspended)
>>>>> ConnectionManagerImpl.releaseConnection() line:
>>>>
>>>>295
>>>>
>>>>
> PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
>
>>>>>line: 240
>>>>>
>>>>>
>>>>
> PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
>
>>>>>line: 418
>>>>> RegisteredSyncs.distributeBefore() line: 110
>>>>> TransactionImpl.internalPrepare() line: 1211
>>>>> TransactionImpl.commit() line: 960
>>>>> TranManagerImpl.commit() line: 150
>>>>> TranManagerSet.commit() line: 182
>>>>>
>>>>>My OJB.properties is as follows:
>>>>>#<!--
>>>>>#/* Copyright 2002-2004 The Apache Software
>>>>
>>>>Foundation
>>>>
>>>>
>>>>># *
>>>>># * Licensed under the Apache License, Version
>>
>>2.0
>>
>>>>>(the "License");
>>>>># * you may not use this file except in
>>
>>compliance
>>
>>>>>with the License.
>>>>># * You may obtain a copy of the License at
>>>>># *
>>>>># *
>>
>>http://www.apache.org/licenses/LICENSE-2.0
>>
>>>>># *
>>>>># * Unless required by applicable law or agreed
>>
>>to
>>
>>>>in
>>>>
>>>>
>>>>>writing, software
>>>>># * distributed under the License is distributed
>>>>
>>>>on an
>>>>
>>>>
>>>>>"AS IS" BASIS,
>>>>># * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
>>>>>either express or implied.
>>>>># * See the License for the specific language
>>>>>governing permissions and
>>>>># * limitations under the License.
>>>>># */
>>>>>#-->
>>>>># OJB.properties -- configuration of the OJB
>>>>
>>>>runtime
>>>>
>>>>
>>>>>environment
>>>>># Version: 1.0
>>>>># (c) 2001, 2002, 2003 Apache Software Foundation
>>>>># Author: Thomas Mahler and many others
>>>>># @version $Id: OJB.properties,v 1.70 2004/06/03
>>>>>23:46:08 arminw Exp $
>>>>>#
>>>>>
>>>>
> #----------------------------------------------------------------------------------------
>
>>>>># repository file settings
>>>>>
>>>>
> #----------------------------------------------------------------------------------------
>
>>>>># The repositoryFile entry tells OJB to use this
>>>>
>>>>file
>>>>
>>>>
>>>>>as as its standard mapping
>>>>># repository. The file is looked up from the
>>>>>classpath.
>>>>>#
>>>>>repositoryFile=repository.xml
>>>>>#
>>>>># If the useSerializedRepository entry is set to
>>>>
>>>>true,
>>>>
>>>>
>>>>>OJB tries to load a
>>>>># serialized version of the repository for
>>>>
>>>>performance
>>>>
>>>>
>>>>>reasons.
>>>>># if set to false, OJB always loads the xml file.
>>>>># Setting this flag to true will accelerate the
>>>>>startup sequence of OJB.
>>>>># If set to true changes to the repository.xml
>>>>
>>>>file
>>>>
>>>>
>>>>>will only be detected
>>>>># after maually deleting the
>>>>
>>>>repository.xml.serialized
>>
> === message truncated ===
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: New Warnings in Managed Environment with RC7
Posted by Gary <gl...@yahoo.com>.
Armin:
Thanks again for your help.
Do you mean that I should close the PB before the
commit is called? If so, I tried it, with the same
results.
I am still confused as to what the correct ordering of
PB opens/closes and commit/rollback operations are.
This all worked great before I moved to RC7. I can't
remember if I was on RC5 or RC6 before...
Gary
--- Armin Waibel <ar...@apache.org> wrote:
> Hi Gary,
>
> Gary wrote:
>
> > No, I first commit or rollback the transaction,
> and
> > then close the PB.
> >
>
> ok, so I think this is the reason for the failure.
> In managed
> environments the PB instance has the same behavior
> as a DataSource in
> managed environments. Means that you operate with an
> PB handle instance
> (wraps the real PB instance) and after use you have
> to close the handle
> instance. If you use an connection from a DataSource
> in an managed
> environment you have to close the connection before
> the tx was completed
> too (I think so).
>
> Maybe it will be better only to log an warning
> instead of throwing an
> exception in this case.
>
> regards,
> Armin
>
> > Gary
> >
> > --- Armin Waibel <ar...@apache.org> wrote:
> >
> >>Gary wrote:
> >>
> >>
> >>>Armin:
> >>>
> >>>Thanks for the quick reply. Do you guys have a
> >>>"contribute" site like SourceForge so I could buy
> >>
> >>you
> >>
> >>>a beer?
> >>>
> >>
> >>Think I should avoid to drink alcohol, because
> your
> >>problem seems really
> >>sophisticated ;-)
> >>
> >>
> >>
> >>>No, I wasn't using the "Sync" factory. When I
> >>
> >>change
> >>
> >>>to it, I get a new error:
> >>>2004-06-15 15:19:29,798 ERROR [TCP
> >>>Connection(7)-172.24.54.129] Connection is in
> >>
> >>local
> >>
> >>>transaction, do a 'localCommit' or
> 'localRollback'
> >>>beforeperform the connection release - rollback
> >>
> >>the
> >>
> >>>connection now
> >>>
> >>
> >
>
(org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java))
> >
> >>hmm, do you close the PB instance within the used
> >>method or before the
> >>tx demarcation ends?
> >>I assume you don't.
> >>
> >>regards,
> >>Armin
> >>
> >>
> >>
> >>>
> >>>It has the following stack trace:
> >>>System Thread [TCP Connection(7)-172.24.54.129]
> >>>(Suspended)
> >>> ConnectionManagerImpl.releaseConnection() line:
> >>
> >>295
> >>
> >>>
> >
>
PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
> >
> >>>line: 240
> >>>
> >>>
> >>
> >
>
PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
> >
> >>>line: 418
> >>> RegisteredSyncs.distributeBefore() line: 110
> >>> TransactionImpl.internalPrepare() line: 1211
> >>> TransactionImpl.commit() line: 960
> >>> TranManagerImpl.commit() line: 150
> >>> TranManagerSet.commit() line: 182
> >>>
> >>>My OJB.properties is as follows:
> >>>#<!--
> >>>#/* Copyright 2002-2004 The Apache Software
> >>
> >>Foundation
> >>
> >>># *
> >>># * Licensed under the Apache License, Version
> 2.0
> >>>(the "License");
> >>># * you may not use this file except in
> compliance
> >>>with the License.
> >>># * You may obtain a copy of the License at
> >>># *
> >>># *
> http://www.apache.org/licenses/LICENSE-2.0
> >>># *
> >>># * Unless required by applicable law or agreed
> to
> >>
> >>in
> >>
> >>>writing, software
> >>># * distributed under the License is distributed
> >>
> >>on an
> >>
> >>>"AS IS" BASIS,
> >>># * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
> >>>either express or implied.
> >>># * See the License for the specific language
> >>>governing permissions and
> >>># * limitations under the License.
> >>># */
> >>>#-->
> >>># OJB.properties -- configuration of the OJB
> >>
> >>runtime
> >>
> >>>environment
> >>># Version: 1.0
> >>># (c) 2001, 2002, 2003 Apache Software Foundation
> >>># Author: Thomas Mahler and many others
> >>># @version $Id: OJB.properties,v 1.70 2004/06/03
> >>>23:46:08 arminw Exp $
> >>>#
> >>>
> >>
> >
>
#----------------------------------------------------------------------------------------
> >
> >>># repository file settings
> >>>
> >>
> >
>
#----------------------------------------------------------------------------------------
> >
> >>># The repositoryFile entry tells OJB to use this
> >>
> >>file
> >>
> >>>as as its standard mapping
> >>># repository. The file is looked up from the
> >>>classpath.
> >>>#
> >>>repositoryFile=repository.xml
> >>>#
> >>># If the useSerializedRepository entry is set to
> >>
> >>true,
> >>
> >>>OJB tries to load a
> >>># serialized version of the repository for
> >>
> >>performance
> >>
> >>>reasons.
> >>># if set to false, OJB always loads the xml file.
> >>># Setting this flag to true will accelerate the
> >>>startup sequence of OJB.
> >>># If set to true changes to the repository.xml
> >>
> >>file
> >>
> >>>will only be detected
> >>># after maually deleting the
> >>
> >>repository.xml.serialized
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: New Warnings in Managed Environment with RC7
Posted by Armin Waibel <ar...@apache.org>.
Hi Gary,
Gary wrote:
> No, I first commit or rollback the transaction, and
> then close the PB.
>
ok, so I think this is the reason for the failure. In managed
environments the PB instance has the same behavior as a DataSource in
managed environments. Means that you operate with an PB handle instance
(wraps the real PB instance) and after use you have to close the handle
instance. If you use an connection from a DataSource in an managed
environment you have to close the connection before the tx was completed
too (I think so).
Maybe it will be better only to log an warning instead of throwing an
exception in this case.
regards,
Armin
> Gary
>
> --- Armin Waibel <ar...@apache.org> wrote:
>
>>Gary wrote:
>>
>>
>>>Armin:
>>>
>>>Thanks for the quick reply. Do you guys have a
>>>"contribute" site like SourceForge so I could buy
>>
>>you
>>
>>>a beer?
>>>
>>
>>Think I should avoid to drink alcohol, because your
>>problem seems really
>>sophisticated ;-)
>>
>>
>>
>>>No, I wasn't using the "Sync" factory. When I
>>
>>change
>>
>>>to it, I get a new error:
>>>2004-06-15 15:19:29,798 ERROR [TCP
>>>Connection(7)-172.24.54.129] Connection is in
>>
>>local
>>
>>>transaction, do a 'localCommit' or 'localRollback'
>>>beforeperform the connection release - rollback
>>
>>the
>>
>>>connection now
>>>
>>
> (org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java))
>
>>hmm, do you close the PB instance within the used
>>method or before the
>>tx demarcation ends?
>>I assume you don't.
>>
>>regards,
>>Armin
>>
>>
>>
>>>
>>>It has the following stack trace:
>>>System Thread [TCP Connection(7)-172.24.54.129]
>>>(Suspended)
>>> ConnectionManagerImpl.releaseConnection() line:
>>
>>295
>>
>>>
> PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
>
>>>line: 240
>>>
>>>
>>
> PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
>
>>>line: 418
>>> RegisteredSyncs.distributeBefore() line: 110
>>> TransactionImpl.internalPrepare() line: 1211
>>> TransactionImpl.commit() line: 960
>>> TranManagerImpl.commit() line: 150
>>> TranManagerSet.commit() line: 182
>>>
>>>My OJB.properties is as follows:
>>>#<!--
>>>#/* Copyright 2002-2004 The Apache Software
>>
>>Foundation
>>
>>># *
>>># * Licensed under the Apache License, Version 2.0
>>>(the "License");
>>># * you may not use this file except in compliance
>>>with the License.
>>># * You may obtain a copy of the License at
>>># *
>>># * http://www.apache.org/licenses/LICENSE-2.0
>>># *
>>># * Unless required by applicable law or agreed to
>>
>>in
>>
>>>writing, software
>>># * distributed under the License is distributed
>>
>>on an
>>
>>>"AS IS" BASIS,
>>># * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
>>>either express or implied.
>>># * See the License for the specific language
>>>governing permissions and
>>># * limitations under the License.
>>># */
>>>#-->
>>># OJB.properties -- configuration of the OJB
>>
>>runtime
>>
>>>environment
>>># Version: 1.0
>>># (c) 2001, 2002, 2003 Apache Software Foundation
>>># Author: Thomas Mahler and many others
>>># @version $Id: OJB.properties,v 1.70 2004/06/03
>>>23:46:08 arminw Exp $
>>>#
>>>
>>
> #----------------------------------------------------------------------------------------
>
>>># repository file settings
>>>
>>
> #----------------------------------------------------------------------------------------
>
>>># The repositoryFile entry tells OJB to use this
>>
>>file
>>
>>>as as its standard mapping
>>># repository. The file is looked up from the
>>>classpath.
>>>#
>>>repositoryFile=repository.xml
>>>#
>>># If the useSerializedRepository entry is set to
>>
>>true,
>>
>>>OJB tries to load a
>>># serialized version of the repository for
>>
>>performance
>>
>>>reasons.
>>># if set to false, OJB always loads the xml file.
>>># Setting this flag to true will accelerate the
>>>startup sequence of OJB.
>>># If set to true changes to the repository.xml
>>
>>file
>>
>>>will only be detected
>>># after maually deleting the
>>
>>repository.xml.serialized
>>
>>>file.
>>>useSerializedRepository=false
>>>#
>>># If Repository serialization is used the entry
>>>serializedRepositoryPath defines the
>>># directory where the Repository is written to and
>>>read from.
>>># this entry is used only when the
>>>useSerializedRepository flag is set to true
>>>#
>>>serializedRepositoryPath=.
>>>#
>>>
>>
> #----------------------------------------------------------------------------------------
>
>>># PersistenceBrokerFactory / PersistenceBroker
>>>
>>
> #----------------------------------------------------------------------------------------
>
>>># The PersistenceBrokerFactoryClass entry decides
>>>which concrete
>>># PersistenceBrokerFactory implemention is to be
>>
>>used.
>>
> #PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>
>>># If in managed environment *only* the PB-api was
>>
>>used
>>
>>>it's recommended to use this factory
>>># to enable the PersistenceBroker instances to
>>>participate in the JTA transaction. This makes
>>># e.g. PBStateListener work properly in managed
>>>environments.
>>>
>>
> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
>
>>>#
>>>#
>>># The PersistenceBrokerClass entry decides which
>>>concrete PersistenceBroker
>>># implementation is to be served by the
>>>PersistenceBrokerFactory.
>>># This is the singlevm implementation:
>>>
>>
> PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl
>
> #PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>
>>>#
>>># This is an implementation that uses Prevayler
>>>(prevayler.sf.net) as the persistent storage.
>>># Using this implementation OJB works as a simple
>>>OODBMS
>>>
>>
> #PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
>
>>>#
>>>
>>
> #----------------------------------------------------------------------------------------
>
>>># 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=100
>>>#
>>># 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
>>>#
>>
> === message truncated ===
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: New Warnings in Managed Environment with RC7
Posted by Gary <gl...@yahoo.com>.
It appears as though beginTransaction() is called on
the given PersistenceBroker instance when it is
created. Then, when a JTA commit operation occurs, it
tries to release the connection (as shown in the stack
trace below) but thinks that a local transaction is
active.
I assume that with a JTA transaction, no local
transaction should be involved. I see there were
changes in this (these messages appear new).
Is anyone else seeing this behavior?
Gary
--- Gary <gl...@yahoo.com> wrote:
> No, I first commit or rollback the transaction, and
> then close the PB.
>
> Gary
>
> --- Armin Waibel <ar...@apache.org> wrote:
> > Gary wrote:
> >
> > > Armin:
> > >
> > > Thanks for the quick reply. Do you guys have a
> > > "contribute" site like SourceForge so I could
> buy
> > you
> > > a beer?
> > >
> >
> > Think I should avoid to drink alcohol, because
> your
> > problem seems really
> > sophisticated ;-)
> >
> >
> > > No, I wasn't using the "Sync" factory. When I
> > change
> > > to it, I get a new error:
> > > 2004-06-15 15:19:29,798 ERROR [TCP
> > > Connection(7)-172.24.54.129] Connection is in
> > local
> > > transaction, do a 'localCommit' or
> 'localRollback'
> > > beforeperform the connection release - rollback
> > the
> > > connection now
> > >
> >
>
(org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java))
> > >
> >
> > hmm, do you close the PB instance within the used
> > method or before the
> > tx demarcation ends?
> > I assume you don't.
> >
> > regards,
> > Armin
> >
> >
> > >
> > >
> > > It has the following stack trace:
> > > System Thread [TCP Connection(7)-172.24.54.129]
> > > (Suspended)
> > > ConnectionManagerImpl.releaseConnection() line:
> > 295
> > >
> > >
> >
>
PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
> > > line: 240
> > >
> > >
> >
>
PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
> > > line: 418
> > > RegisteredSyncs.distributeBefore() line: 110
> > > TransactionImpl.internalPrepare() line: 1211
> > > TransactionImpl.commit() line: 960
> > > TranManagerImpl.commit() line: 150
> > > TranManagerSet.commit() line: 182
> > >
> > > My OJB.properties is as follows:
> > > #<!--
> > > #/* Copyright 2002-2004 The Apache Software
> > Foundation
> > > # *
> > > # * Licensed under the Apache License, Version
> 2.0
> > > (the "License");
> > > # * you may not use this file except in
> compliance
> > > with the License.
> > > # * You may obtain a copy of the License at
> > > # *
> > > # *
> http://www.apache.org/licenses/LICENSE-2.0
> > > # *
> > > # * Unless required by applicable law or agreed
> to
> > in
> > > writing, software
> > > # * distributed under the License is distributed
> > on an
> > > "AS IS" BASIS,
> > > # * WITHOUT WARRANTIES OR CONDITIONS OF ANY
> KIND,
> > > either express or implied.
> > > # * See the License for the specific language
> > > governing permissions and
> > > # * limitations under the License.
> > > # */
> > > #-->
> > > # OJB.properties -- configuration of the OJB
> > runtime
> > > environment
> > > # Version: 1.0
> > > # (c) 2001, 2002, 2003 Apache Software
> Foundation
> > > # Author: Thomas Mahler and many others
> > > # @version $Id: OJB.properties,v 1.70 2004/06/03
> > > 23:46:08 arminw Exp $
> > > #
> > >
> >
>
#----------------------------------------------------------------------------------------
> > > # repository file settings
> > >
> >
>
#----------------------------------------------------------------------------------------
> > > # The repositoryFile entry tells OJB to use this
> > file
> > > as as its standard mapping
> > > # repository. The file is looked up from the
> > > classpath.
> > > #
> > > repositoryFile=repository.xml
> > > #
> > > # If the useSerializedRepository entry is set to
> > true,
> > > OJB tries to load a
> > > # serialized version of the repository for
> > performance
> > > reasons.
> > > # if set to false, OJB always loads the xml
> file.
> > > # Setting this flag to true will accelerate the
> > > startup sequence of OJB.
> > > # If set to true changes to the repository.xml
> > file
> > > will only be detected
> > > # after maually deleting the
> > repository.xml.serialized
> > > file.
> > > useSerializedRepository=false
> > > #
> > > # If Repository serialization is used the entry
> > > serializedRepositoryPath defines the
> > > # directory where the Repository is written to
> and
> > > read from.
> > > # this entry is used only when the
> > > useSerializedRepository flag is set to true
> > > #
> > > serializedRepositoryPath=.
> > > #
> > >
> >
>
#----------------------------------------------------------------------------------------
> > > # PersistenceBrokerFactory / PersistenceBroker
> > >
> >
>
#----------------------------------------------------------------------------------------
> > > # The PersistenceBrokerFactoryClass entry
> decides
> > > which concrete
> > > # PersistenceBrokerFactory implemention is to be
> > used.
> > >
> >
>
#PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
> > > # If in managed environment *only* the PB-api
> was
> > used
> > > it's recommended to use this factory
> > > # to enable the PersistenceBroker instances to
> > > participate in the JTA transaction. This makes
> > > # e.g. PBStateListener work properly in managed
> > > environments.
> > >
> >
>
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
> > > #
> > > #
> > > # The PersistenceBrokerClass entry decides which
> > > concrete PersistenceBroker
> > > # implementation is to be served by the
> > > PersistenceBrokerFactory.
> > > # This is the singlevm implementation:
> > >
> >
>
PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl
> > >
> >
>
#PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
> > > #
> > > # This is an implementation that uses Prevayler
> > > (prevayler.sf.net) as the persistent storage.
> > > # Using this implementation OJB works as a
> simple
> > > OODBMS
> > >
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: New Warnings in Managed Environment with RC7
Posted by Gary <gl...@yahoo.com>.
No, I first commit or rollback the transaction, and
then close the PB.
Gary
--- Armin Waibel <ar...@apache.org> wrote:
> Gary wrote:
>
> > Armin:
> >
> > Thanks for the quick reply. Do you guys have a
> > "contribute" site like SourceForge so I could buy
> you
> > a beer?
> >
>
> Think I should avoid to drink alcohol, because your
> problem seems really
> sophisticated ;-)
>
>
> > No, I wasn't using the "Sync" factory. When I
> change
> > to it, I get a new error:
> > 2004-06-15 15:19:29,798 ERROR [TCP
> > Connection(7)-172.24.54.129] Connection is in
> local
> > transaction, do a 'localCommit' or 'localRollback'
> > beforeperform the connection release - rollback
> the
> > connection now
> >
>
(org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java))
> >
>
> hmm, do you close the PB instance within the used
> method or before the
> tx demarcation ends?
> I assume you don't.
>
> regards,
> Armin
>
>
> >
> >
> > It has the following stack trace:
> > System Thread [TCP Connection(7)-172.24.54.129]
> > (Suspended)
> > ConnectionManagerImpl.releaseConnection() line:
> 295
> >
> >
>
PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
> > line: 240
> >
> >
>
PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
> > line: 418
> > RegisteredSyncs.distributeBefore() line: 110
> > TransactionImpl.internalPrepare() line: 1211
> > TransactionImpl.commit() line: 960
> > TranManagerImpl.commit() line: 150
> > TranManagerSet.commit() line: 182
> >
> > My OJB.properties is as follows:
> > #<!--
> > #/* Copyright 2002-2004 The Apache Software
> Foundation
> > # *
> > # * Licensed under the Apache License, Version 2.0
> > (the "License");
> > # * you may not use this file except in compliance
> > with the License.
> > # * You may obtain a copy of the License at
> > # *
> > # * http://www.apache.org/licenses/LICENSE-2.0
> > # *
> > # * Unless required by applicable law or agreed to
> in
> > writing, software
> > # * distributed under the License is distributed
> on an
> > "AS IS" BASIS,
> > # * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
> > either express or implied.
> > # * See the License for the specific language
> > governing permissions and
> > # * limitations under the License.
> > # */
> > #-->
> > # OJB.properties -- configuration of the OJB
> runtime
> > environment
> > # Version: 1.0
> > # (c) 2001, 2002, 2003 Apache Software Foundation
> > # Author: Thomas Mahler and many others
> > # @version $Id: OJB.properties,v 1.70 2004/06/03
> > 23:46:08 arminw Exp $
> > #
> >
>
#----------------------------------------------------------------------------------------
> > # repository file settings
> >
>
#----------------------------------------------------------------------------------------
> > # The repositoryFile entry tells OJB to use this
> file
> > as as its standard mapping
> > # repository. The file is looked up from the
> > classpath.
> > #
> > repositoryFile=repository.xml
> > #
> > # If the useSerializedRepository entry is set to
> true,
> > OJB tries to load a
> > # serialized version of the repository for
> performance
> > reasons.
> > # if set to false, OJB always loads the xml file.
> > # Setting this flag to true will accelerate the
> > startup sequence of OJB.
> > # If set to true changes to the repository.xml
> file
> > will only be detected
> > # after maually deleting the
> repository.xml.serialized
> > file.
> > useSerializedRepository=false
> > #
> > # If Repository serialization is used the entry
> > serializedRepositoryPath defines the
> > # directory where the Repository is written to and
> > read from.
> > # this entry is used only when the
> > useSerializedRepository flag is set to true
> > #
> > serializedRepositoryPath=.
> > #
> >
>
#----------------------------------------------------------------------------------------
> > # PersistenceBrokerFactory / PersistenceBroker
> >
>
#----------------------------------------------------------------------------------------
> > # The PersistenceBrokerFactoryClass entry decides
> > which concrete
> > # PersistenceBrokerFactory implemention is to be
> used.
> >
>
#PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
> > # If in managed environment *only* the PB-api was
> used
> > it's recommended to use this factory
> > # to enable the PersistenceBroker instances to
> > participate in the JTA transaction. This makes
> > # e.g. PBStateListener work properly in managed
> > environments.
> >
>
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
> > #
> > #
> > # The PersistenceBrokerClass entry decides which
> > concrete PersistenceBroker
> > # implementation is to be served by the
> > PersistenceBrokerFactory.
> > # This is the singlevm implementation:
> >
>
PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl
> >
>
#PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
> > #
> > # This is an implementation that uses Prevayler
> > (prevayler.sf.net) as the persistent storage.
> > # Using this implementation OJB works as a simple
> > OODBMS
> >
>
#PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
> > #
> >
>
#----------------------------------------------------------------------------------------
> > # 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=100
> > #
> > # 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
> > #
>
=== message truncated ===
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: New Warnings in Managed Environment with RC7
Posted by Armin Waibel <ar...@apache.org>.
Gary wrote:
> Armin:
>
> Thanks for the quick reply. Do you guys have a
> "contribute" site like SourceForge so I could buy you
> a beer?
>
Think I should avoid to drink alcohol, because your problem seems really
sophisticated ;-)
> No, I wasn't using the "Sync" factory. When I change
> to it, I get a new error:
> 2004-06-15 15:19:29,798 ERROR [TCP
> Connection(7)-172.24.54.129] Connection is in local
> transaction, do a 'localCommit' or 'localRollback'
> beforeperform the connection release - rollback the
> connection now
> (org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java))
>
hmm, do you close the PB instance within the used method or before the
tx demarcation ends?
I assume you don't.
regards,
Armin
>
>
> It has the following stack trace:
> System Thread [TCP Connection(7)-172.24.54.129]
> (Suspended)
> ConnectionManagerImpl.releaseConnection() line: 295
>
> PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
> line: 240
>
> PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
> line: 418
> RegisteredSyncs.distributeBefore() line: 110
> TransactionImpl.internalPrepare() line: 1211
> TransactionImpl.commit() line: 960
> TranManagerImpl.commit() line: 150
> TranManagerSet.commit() line: 182
>
> My OJB.properties is as follows:
> #<!--
> #/* Copyright 2002-2004 The Apache Software Foundation
> # *
> # * Licensed under the Apache License, Version 2.0
> (the "License");
> # * you may not use this file except in compliance
> with the License.
> # * You may obtain a copy of the License at
> # *
> # * http://www.apache.org/licenses/LICENSE-2.0
> # *
> # * Unless required by applicable law or agreed to in
> writing, software
> # * distributed under the License is distributed on an
> "AS IS" BASIS,
> # * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
> either express or implied.
> # * See the License for the specific language
> governing permissions and
> # * limitations under the License.
> # */
> #-->
> # OJB.properties -- configuration of the OJB runtime
> environment
> # Version: 1.0
> # (c) 2001, 2002, 2003 Apache Software Foundation
> # Author: Thomas Mahler and many others
> # @version $Id: OJB.properties,v 1.70 2004/06/03
> 23:46:08 arminw Exp $
> #
> #----------------------------------------------------------------------------------------
> # repository file settings
> #----------------------------------------------------------------------------------------
> # The repositoryFile entry tells OJB to use this file
> as as its standard mapping
> # repository. The file is looked up from the
> classpath.
> #
> repositoryFile=repository.xml
> #
> # If the useSerializedRepository entry is set to true,
> OJB tries to load a
> # serialized version of the repository for performance
> reasons.
> # if set to false, OJB always loads the xml file.
> # Setting this flag to true will accelerate the
> startup sequence of OJB.
> # If set to true changes to the repository.xml file
> will only be detected
> # after maually deleting the repository.xml.serialized
> file.
> useSerializedRepository=false
> #
> # If Repository serialization is used the entry
> serializedRepositoryPath defines the
> # directory where the Repository is written to and
> read from.
> # this entry is used only when the
> useSerializedRepository flag is set to true
> #
> serializedRepositoryPath=.
> #
> #----------------------------------------------------------------------------------------
> # PersistenceBrokerFactory / PersistenceBroker
> #----------------------------------------------------------------------------------------
> # The PersistenceBrokerFactoryClass entry decides
> which concrete
> # PersistenceBrokerFactory implemention is to be used.
> #PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
> # If in managed environment *only* the PB-api was used
> it's recommended to use this factory
> # to enable the PersistenceBroker instances to
> participate in the JTA transaction. This makes
> # e.g. PBStateListener work properly in managed
> environments.
> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
> #
> #
> # The PersistenceBrokerClass entry decides which
> concrete PersistenceBroker
> # implementation is to be served by the
> PersistenceBrokerFactory.
> # This is the singlevm implementation:
> PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl
> #PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
> #
> # This is an implementation that uses Prevayler
> (prevayler.sf.net) as the persistent storage.
> # Using this implementation OJB works as a simple
> OODBMS
> #PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
> #
> #----------------------------------------------------------------------------------------
> # 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=100
> #
> # 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=0
> #
> #
> #----------------------------------------------------------------------------------------
> # ConnectionFactory / Default ConnectionPool
> #----------------------------------------------------------------------------------------
> # The ConnectionFactoryClass entry determines which
> kind of ConnectionFactory
> # is to be used within org.apache.ojb as connection
> factory.
> # A ConnectionFactory is responsible for creating
> # JDBC Connections. Current version ships four
> implementations:
> #
> # 1. ConnectionFactoryNotPooledImpl
> # No pooling, no playing around.
> # Every connection request returns a new
> connection,
> # every connection release close the connection.
> # 2. ConnectionFactoryPooledImpl
> # This implementation supports connection pooling.
> # 3. ConnectionFactoryDBCPImpl
> # Using the jakarta-DBCP api for connection
> management, support
> # connection- and prepared statement-pooling,
> abandoned connection handling.
> # 4. ConnectionFactoryManagedImpl
> # Connection factory for use within managed
> environments - e.g. JBoss.
> # Every obtained DataSource was wrapped within OJB
> (and ignore
> # e.g. con.commit() calls within OJB).
> # Use this implementation e.g if you use
> Datasources from an application server.
> #
> # Use the OJB performance tests to decide, which
> implementation is best for you.
> # The proper way of obtaining a connection is
> configured in
> # JDBCConnectionDescriptor entries in the
> repository.xml file.
> # If want a more fine grained control of each
> connection pool used by OJB,
> # take a look at the repository.dtd, there was a
> possibility to override
> # this default connection factory entry in each
> JDBCConnectionDescriptor.
> #
> #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
> #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl
> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
> #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # ConnectionManager
> #----------------------------------------------------------------------------------------
> # The ConnectionManagerClass entry defines the
> ConnectionManager implemementation to be used
> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # SqlGenerator
> #----------------------------------------------------------------------------------------
> # The SqlGeneratorClass entry defines the SqlGenerator
> implemementation to be used
> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # IndirectionHandler
> #----------------------------------------------------------------------------------------
> # The IndirectionHandlerClass entry defines the class
> to be used by OJB's proxies to
> # handle method invocations
> #
> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # ListProxy
> #----------------------------------------------------------------------------------------
> # The ListProxyClass entry defines the proxy class to
> be used for collections that
> # implement the java.util.List interface.
> #
> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # SetProxy
> #----------------------------------------------------------------------------------------
> # The SetProxyClass entry defines the proxy class to
> be used for collections that
> # implement the java.util.Set interface.
> #
> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # CollectionProxy
> #----------------------------------------------------------------------------------------
> # The CollectionProxyClass entry defines the proxy
> class to be used for collections that
> # do not implement java.util.List or java.util.Set.
> #
> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # StatementManager
> #----------------------------------------------------------------------------------------
> # The StatementManagerClass entry defines the
> StatementManager implemementation to be used
> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
> #
> #
> #----------------------------------------------------------------------------------------
> # StatementsForClass
> #----------------------------------------------------------------------------------------
> # The StatementsForClassClass entry defines the
> StatementsForClass implemementation to be used
> # to implement cached statements.
> StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # JdbcAccess
> #----------------------------------------------------------------------------------------
> # The JdbcAccessClass entry defines the JdbcAccess
> implemementation to be used
> JdbcAccessClass=edu.mayo.evolution.infrastructure.ojb.EvolutionJdbcAccessImpl
> #JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # RowReader
> #----------------------------------------------------------------------------------------
> # Set the standard RowReader implementation. It is
> also possible to specify the
> # RowReader on class-descriptor level.
> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
> #
> #----------------------------------------------------------------------------------------
> # Object cache
> #----------------------------------------------------------------------------------------
> # The ObjectCacheClass entry tells OJB which concrete
> ObjectCache
> # implementation is to be used as standard cache.
> # Its also possible to override this entry adding
> object-cache elements
> # on jdbc-connection-descriptor level and
> # per class-descriptor in repository file. More info
> see documentation.
> #
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
> ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
> #
> #
> # This property is only relevant if the per
> class-descriptor object-cache
> # declaration was used in conjunction with metadata
> runtime changes.
> # If set 'flase' the class name of the object is used
> # to find a per class ObjectCache implementation.
> # If set 'true' the ObjectCacheDescriptor instance is
> used as key to
> # find a per class ObjectCache, this enables to use
> different ObjectCache
> # instances for the same class.
> descriptorBasedCaches=false
> #
> #
> # Use CacheFilters to do filter operations before
> caching methods were
> # called. Build your own filter class by implementing
> org.apache.ojb.cache.CacheFilter.
> # It is possible to use a arbitrary number of
> CacheFilters, but this slows
> # down the performance of the cache, thus handle with
> care.
> #
> # - org.apache.ojb.broker.cache.CacheFilterClassImpl
> # allows filtering of classes
> # - org.apache.ojb.broker.cache.CacheFilterPackageImpl
> # allows filtering of packages
> # More info see Javadoc of the according classes.
> # Set a comma separated list of CacheFilter.
> #ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
> #
> #----------------------------------------------------------------------------------------
> # Locking
> #----------------------------------------------------------------------------------------
> # The LockManagerClass entry tells OJB which concrete
> LockManager
> # implementation is to be used.
> LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
> #
> # The LockMapClass entry tells OJB which concrete
> LockMap
> # implementation is to be used.
> # If OJB is running on multiple concurrent clients it
> is recommended
> # to use the RemoteLockMapImpl. It guarantees to
> provide
> # Lockmanagement across multiple JVMs.
> # This Implemenation relies on a Servlet based
> Lockserver. To use it you have to
> # deploy the ojb-lockserver.war into a Servlet engine.
> # and you have to set the Property LockServletUrl to
> point to this servlet.
> # (see LockServletUrl section below).
> # If OJB is running in a single JVM (e.g. in a desktop
> app, or in a servlet
> # engine) it is save to use the InMemoryLockMapImpl.
> Using it will result
> # in a large performance gain.
> #LockMapClass=org.apache.ojb.odmg.locking.RemoteLockMapImpl
> LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
> #
> # The LockTimeout entry defines the maximum time in
> milliseconds
> # that a lock may be hold. Defaults to 60000 = 1
> minute
> LockTimeout=60000
> #
> # The ImplicitLocking entry defines if implicit lock
> acquisition is
> # to be used. If set to true OJB implicitely locks
> objects to ODMG
> # transactions after performing OQL queries.
> # If implicit locking is used locking objects is
> recursive, that is
> # associated objects are also locked.
> # If ImplicitLocking is set to false, no locks are
> obtained in OQL
> # queries and there is also no recursive locking.
> ImplicitLocking=true
> #ImplicitLocking=false
> #
> #
> # The LockServletUrl entry points to the Lockserver
> servlet.
> # This Servlet is addressed by all distributed JVMs if
> the RemoteLockMapImpl
> # is used.
> LockServletUrl=http://127.0.0.1:8080/ojb-lockserver
> #
> #
> # The LockAssociations entry defines the behaviour for
> the OJB
> # implicit locking feature. If set to WRITE (default)
> acquiring a write-
> # lock on a given object x implies write locks on all
> objects associated
> # to x. If set to READ implicit read-locks are
> acquired.
> # Acquiring a read-lock on x thus allways results in
> implicit read-locks
> # on all associated objects.
> #LockAssociations=READ
> LockAssociations=WRITE
> #
> #
> #----------------------------------------------------------------------------------------
> # OQL / SQL settings
> #----------------------------------------------------------------------------------------
> # The OqlCollectionClass entry defines the collection
> type returned
> # from OQL queries. By default this value is set to
> DListImpl.
> # This will be good for most situations as DList
> allows maximum flexibility
> # in a ODMG environment. See also section 'ODMG
> settings'.
> # Using DLists for large resultsets may be bad for
> application performance.
> # For these scenarios you can use ArrayLists or
> Vectors.
> # Important note: the collections class to be used
> MUST implement the
> # interface
> org.apache.ojb.broker.ManageableCollection.
> #
> OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2
> #
> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
> #
> OqlCollectionClass=org.apache.ojb.broker.util.ManageableVector
> #
> # The SqlInLimit entry limits the number of values in
> IN-sql statement,
> # -1 for no limits. This hint is used in Criteria.
> SqlInLimit=200
> #
> #
> #----------------------------------------------------------------------------------------
> # ODMG settings
> #----------------------------------------------------------------------------------------
> # Specify the used base class for ODMG API
> # - ImplementationDefaultImpl is the default class
> # - ImplementationJTAImpl is for use in managed
> environments like J2EE conform
> # Application Server
> #
> #ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
> ImplementationClass=org.apache.ojb.odmg.ImplementationJTAImpl
> #
> #
> # Specify the used tx handling.
> # - LocalTxManager use if you want the transaction to
> be associated by a thread
> # - JTATxManager use if you want the transaction to be
> associated via the Transaction
> # manager that is in your application server.
> #
> #OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
> OJBTxManagerClass=org.apache.ojb.odmg.JTATxManager
> #
> #
> # Used ODMG collection implementation classes
> # (e.g. when do a Implementation#newDlist() call)
> #
> # org.odmg.DList implementation class
> DListClass=org.apache.ojb.odmg.collections.DListImpl_2
> #DListClass=org.apache.ojb.odmg.collections.DListImpl
> #
> # org.odmg.DArray implementation class
> DArrayClass=org.apache.ojb.odmg.collections.DListImpl_2
> #DArrayClass=org.apache.ojb.odmg.collections.DListImpl
> #
> # org.odmg.DMap implementation class
> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
> #
> # org.odmg.DBag implementation class
> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
> #
> # org.odmg.DSet implementation class
> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # Meta data / mapping settings
> #----------------------------------------------------------------------------------------
> # The PersistentFieldClass property defines the
> implementation class
> # for PersistentField attributes used in the OJB
> MetaData layer.
> # By default the best performing attribute/refection
> based implementation
> # is selected (PersistentFieldDirectAccessImpl).
> #
> # - PersistentFieldDirectAccessImpl
> # is a high-speed version of the access strategies.
> # It does not cooperate with an AccessController,
> # but accesses the fields directly. Persistent
> # attributes don't need getters and setters
> # and don't have to be declared public or protected
> # - PersistentFieldPrivilegedImpl
> # Same as above, but does cooperate with
> AccessController and do not
> # suppress the java language access check.
> # - PersistentFieldIntrospectorImpl
> # uses JavaBeans compliant calls only to access
> persistent attributes.
> # No Reflection is needed. But for each attribute
> xxx there must be
> # public getXxx() and setXxx() methods.
> # - PersistentFieldDynaBeanAccessImpl
> # implementation used to access a property from a
> # org.apache.commons.beanutils.DynaBean.
> # - PersistentFieldAutoProxyImpl
> # for each field determines upon first access how to
> access this particular field
> # (directly, as a bean, as a dyna bean) and then
> uses that strategy
> #
> PersistentFieldClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistentFieldIntrospectorImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanAccessImpl
> #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl
> #
> #
> #----------------------------------------------------------------------------------------
> # Component Intercepting for Profiling and Tracing
> #----------------------------------------------------------------------------------------
> # By enabling an InterceptorClass all OJB components
> will use
> # this Interceptor. Interceptors allow advanced
> tracing and Profiling
> # of all component method calls.
> # This is currently an experimental feature useful
> only for OJB kernel developers.
> #
> #InterceptorClass=org.apache.ojb.broker.util.interceptor.TracingInterceptor
> #
> #----------------------------------------------------------------------------------------
> # Transaction Management and assocation
> #----------------------------------------------------------------------------------------
> # (optional, only used when OJB runs within managed
> environments)
> # To praticipate in JTA transaction OJB needs access
> to the underlying transaction manager.
> # The TransactionManager is acquired in different ways
> dependent on the application server.
> # The JTATransactionManagerClass property allows you
> to specify the class that implements
> # the proper behaviour for finding the transaction
> manager. Only use when OJBTxManagerClass
> # is set to a factory that uses the application server
> transaction manager
> # (org.apache.ojb.odmg.JTATxManager)
> #
> #JTATransactionManagerClass=edu.mayo.evolution.infrastructure.ojb.tx.OjbTransactionManagerFactory
> JTATransactionManagerClass=edu.mayo.evolution.infrastructure.ojb.WebSphere5TransactionManagerFactory
> # JBoss Transaction Manager Factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
> # Weblogic Transaction Manager Factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WeblogicTransactionManagerFactory
> # WebSphere transaction manager factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WebSphereTransactionManagerFactory
> # Orion transaction manager factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.OrionTransactionManagerFactory
> # SunOne transaction manager factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.SunOneTransactionManagerFactory
> # JOnAs transaction manager factory
> #JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JOnASTransactionManagerFactory
> #
> #
> #----------------------------------------------------------------------------------------
> # Logging settings are now in their own file,
> OJB-logging.properties
> #----------------------------------------------------------------------------------------
> #----------------------------------------------------------------------------------------
> # End of OJB.properties file
> #----------------------------------------------------------------------------------------
>
>
> --- Armin Waibel <ar...@apache.org> wrote:
>
>>Hi Gary,
>>
>>Gary wrote:
>>
>>
>>>I am now getting the following warnings in a JTA
>>>environment (this worked fine, no messages, before
>>>RC7):
>>>
>>>2004-06-15 13:32:26,728 WARN
>>>[Servlet.Engine.Transports : 0] No running tx
>>
>>found,
>>
>>>please only delete objects in context of an
>>>PB-transaction, to avoid side-effects - e.g. when
>>>rollback of complex objects
>>>
>>
> (org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java))
>
>>>
>>>Looking into the code, it appears as though I am
>>
>>now
>>
>>>required to do a pb.beginTransaction() in even a
>>>managed environment. Am I missing something?
>>>
>>
>>I assume you use PB-api in managed environment and
>>when deleting an
>>object you use a JTA-tx?
>>
>>Did you set
>>
>
> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
>
>>in OJB.properties (introduced in rc6)?
>>
>>regards,
>>Armin
>>
>>
>>>Thanks for all your hard work, Gary
>>>
>>>
>>>
>>>__________________________________
>>>Do you Yahoo!?
>>>Yahoo! Mail is new and improved - Check it out!
>>>http://promotions.yahoo.com/new_mail
>>>
>>>
>>
> ---------------------------------------------------------------------
>
>>>To unsubscribe, e-mail:
>>
>>ojb-user-unsubscribe@db.apache.org
>>
>>>For additional commands, e-mail:
>>
>>ojb-user-help@db.apache.org
>>
>>>
>>>
>>
> ---------------------------------------------------------------------
>
>>To unsubscribe, e-mail:
>>ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail:
>>ojb-user-help@db.apache.org
>>
>>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: New Warnings in Managed Environment with RC7
Posted by Gary <gl...@yahoo.com>.
Armin:
Thanks for the quick reply. Do you guys have a
"contribute" site like SourceForge so I could buy you
a beer?
No, I wasn't using the "Sync" factory. When I change
to it, I get a new error:
2004-06-15 15:19:29,798 ERROR [TCP
Connection(7)-172.24.54.129] Connection is in local
transaction, do a 'localCommit' or 'localRollback'
beforeperform the connection release - rollback the
connection now
(org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java))
It has the following stack trace:
System Thread [TCP Connection(7)-172.24.54.129]
(Suspended)
ConnectionManagerImpl.releaseConnection() line: 295
PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion()
line: 240
PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion()
line: 418
RegisteredSyncs.distributeBefore() line: 110
TransactionImpl.internalPrepare() line: 1211
TransactionImpl.commit() line: 960
TranManagerImpl.commit() line: 150
TranManagerSet.commit() line: 182
My OJB.properties is as follows:
#<!--
#/* Copyright 2002-2004 The Apache Software Foundation
# *
# * Licensed under the Apache License, Version 2.0
(the "License");
# * you may not use this file except in compliance
with the License.
# * You may obtain a copy of the License at
# *
# * http://www.apache.org/licenses/LICENSE-2.0
# *
# * Unless required by applicable law or agreed to in
writing, software
# * distributed under the License is distributed on an
"AS IS" BASIS,
# * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied.
# * See the License for the specific language
governing permissions and
# * limitations under the License.
# */
#-->
# OJB.properties -- configuration of the OJB runtime
environment
# Version: 1.0
# (c) 2001, 2002, 2003 Apache Software Foundation
# Author: Thomas Mahler and many others
# @version $Id: OJB.properties,v 1.70 2004/06/03
23:46:08 arminw Exp $
#
#----------------------------------------------------------------------------------------
# repository file settings
#----------------------------------------------------------------------------------------
# The repositoryFile entry tells OJB to use this file
as as its standard mapping
# repository. The file is looked up from the
classpath.
#
repositoryFile=repository.xml
#
# If the useSerializedRepository entry is set to true,
OJB tries to load a
# serialized version of the repository for performance
reasons.
# if set to false, OJB always loads the xml file.
# Setting this flag to true will accelerate the
startup sequence of OJB.
# If set to true changes to the repository.xml file
will only be detected
# after maually deleting the repository.xml.serialized
file.
useSerializedRepository=false
#
# If Repository serialization is used the entry
serializedRepositoryPath defines the
# directory where the Repository is written to and
read from.
# this entry is used only when the
useSerializedRepository flag is set to true
#
serializedRepositoryPath=.
#
#----------------------------------------------------------------------------------------
# PersistenceBrokerFactory / PersistenceBroker
#----------------------------------------------------------------------------------------
# The PersistenceBrokerFactoryClass entry decides
which concrete
# PersistenceBrokerFactory implemention is to be used.
#PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
# If in managed environment *only* the PB-api was used
it's recommended to use this factory
# to enable the PersistenceBroker instances to
participate in the JTA transaction. This makes
# e.g. PBStateListener work properly in managed
environments.
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
#
#
# The PersistenceBrokerClass entry decides which
concrete PersistenceBroker
# implementation is to be served by the
PersistenceBrokerFactory.
# This is the singlevm implementation:
PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl
#PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
#
# This is an implementation that uses Prevayler
(prevayler.sf.net) as the persistent storage.
# Using this implementation OJB works as a simple
OODBMS
#PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl
#
#----------------------------------------------------------------------------------------
# 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=100
#
# 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=0
#
#
#----------------------------------------------------------------------------------------
# ConnectionFactory / Default ConnectionPool
#----------------------------------------------------------------------------------------
# The ConnectionFactoryClass entry determines which
kind of ConnectionFactory
# is to be used within org.apache.ojb as connection
factory.
# A ConnectionFactory is responsible for creating
# JDBC Connections. Current version ships four
implementations:
#
# 1. ConnectionFactoryNotPooledImpl
# No pooling, no playing around.
# Every connection request returns a new
connection,
# every connection release close the connection.
# 2. ConnectionFactoryPooledImpl
# This implementation supports connection pooling.
# 3. ConnectionFactoryDBCPImpl
# Using the jakarta-DBCP api for connection
management, support
# connection- and prepared statement-pooling,
abandoned connection handling.
# 4. ConnectionFactoryManagedImpl
# Connection factory for use within managed
environments - e.g. JBoss.
# Every obtained DataSource was wrapped within OJB
(and ignore
# e.g. con.commit() calls within OJB).
# Use this implementation e.g if you use
Datasources from an application server.
#
# Use the OJB performance tests to decide, which
implementation is best for you.
# The proper way of obtaining a connection is
configured in
# JDBCConnectionDescriptor entries in the
repository.xml file.
# If want a more fine grained control of each
connection pool used by OJB,
# take a look at the repository.dtd, there was a
possibility to override
# this default connection factory entry in each
JDBCConnectionDescriptor.
#
#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
#ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl
#
#
#----------------------------------------------------------------------------------------
# ConnectionManager
#----------------------------------------------------------------------------------------
# The ConnectionManagerClass entry defines the
ConnectionManager implemementation to be used
ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
#
#
#----------------------------------------------------------------------------------------
# SqlGenerator
#----------------------------------------------------------------------------------------
# The SqlGeneratorClass entry defines the SqlGenerator
implemementation to be used
SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
#
#
#----------------------------------------------------------------------------------------
# IndirectionHandler
#----------------------------------------------------------------------------------------
# The IndirectionHandlerClass entry defines the class
to be used by OJB's proxies to
# handle method invocations
#
IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
#
#----------------------------------------------------------------------------------------
# ListProxy
#----------------------------------------------------------------------------------------
# The ListProxyClass entry defines the proxy class to
be used for collections that
# implement the java.util.List interface.
#
ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
#
#----------------------------------------------------------------------------------------
# SetProxy
#----------------------------------------------------------------------------------------
# The SetProxyClass entry defines the proxy class to
be used for collections that
# implement the java.util.Set interface.
#
SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
#
#----------------------------------------------------------------------------------------
# CollectionProxy
#----------------------------------------------------------------------------------------
# The CollectionProxyClass entry defines the proxy
class to be used for collections that
# do not implement java.util.List or java.util.Set.
#
CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
#
#----------------------------------------------------------------------------------------
# StatementManager
#----------------------------------------------------------------------------------------
# The StatementManagerClass entry defines the
StatementManager implemementation to be used
StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
#
#
#----------------------------------------------------------------------------------------
# StatementsForClass
#----------------------------------------------------------------------------------------
# The StatementsForClassClass entry defines the
StatementsForClass implemementation to be used
# to implement cached statements.
StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl
#
#
#----------------------------------------------------------------------------------------
# JdbcAccess
#----------------------------------------------------------------------------------------
# The JdbcAccessClass entry defines the JdbcAccess
implemementation to be used
JdbcAccessClass=edu.mayo.evolution.infrastructure.ojb.EvolutionJdbcAccessImpl
#JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
#
#
#----------------------------------------------------------------------------------------
# RowReader
#----------------------------------------------------------------------------------------
# Set the standard RowReader implementation. It is
also possible to specify the
# RowReader on class-descriptor level.
RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
#
#----------------------------------------------------------------------------------------
# Object cache
#----------------------------------------------------------------------------------------
# The ObjectCacheClass entry tells OJB which concrete
ObjectCache
# implementation is to be used as standard cache.
# Its also possible to override this entry adding
object-cache elements
# on jdbc-connection-descriptor level and
# per class-descriptor in repository file. More info
see documentation.
#
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
#
#
# This property is only relevant if the per
class-descriptor object-cache
# declaration was used in conjunction with metadata
runtime changes.
# If set 'flase' the class name of the object is used
# to find a per class ObjectCache implementation.
# If set 'true' the ObjectCacheDescriptor instance is
used as key to
# find a per class ObjectCache, this enables to use
different ObjectCache
# instances for the same class.
descriptorBasedCaches=false
#
#
# Use CacheFilters to do filter operations before
caching methods were
# called. Build your own filter class by implementing
org.apache.ojb.cache.CacheFilter.
# It is possible to use a arbitrary number of
CacheFilters, but this slows
# down the performance of the cache, thus handle with
care.
#
# - org.apache.ojb.broker.cache.CacheFilterClassImpl
# allows filtering of classes
# - org.apache.ojb.broker.cache.CacheFilterPackageImpl
# allows filtering of packages
# More info see Javadoc of the according classes.
# Set a comma separated list of CacheFilter.
#ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
#
#----------------------------------------------------------------------------------------
# Locking
#----------------------------------------------------------------------------------------
# The LockManagerClass entry tells OJB which concrete
LockManager
# implementation is to be used.
LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
#
# The LockMapClass entry tells OJB which concrete
LockMap
# implementation is to be used.
# If OJB is running on multiple concurrent clients it
is recommended
# to use the RemoteLockMapImpl. It guarantees to
provide
# Lockmanagement across multiple JVMs.
# This Implemenation relies on a Servlet based
Lockserver. To use it you have to
# deploy the ojb-lockserver.war into a Servlet engine.
# and you have to set the Property LockServletUrl to
point to this servlet.
# (see LockServletUrl section below).
# If OJB is running in a single JVM (e.g. in a desktop
app, or in a servlet
# engine) it is save to use the InMemoryLockMapImpl.
Using it will result
# in a large performance gain.
#LockMapClass=org.apache.ojb.odmg.locking.RemoteLockMapImpl
LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
#
# The LockTimeout entry defines the maximum time in
milliseconds
# that a lock may be hold. Defaults to 60000 = 1
minute
LockTimeout=60000
#
# The ImplicitLocking entry defines if implicit lock
acquisition is
# to be used. If set to true OJB implicitely locks
objects to ODMG
# transactions after performing OQL queries.
# If implicit locking is used locking objects is
recursive, that is
# associated objects are also locked.
# If ImplicitLocking is set to false, no locks are
obtained in OQL
# queries and there is also no recursive locking.
ImplicitLocking=true
#ImplicitLocking=false
#
#
# The LockServletUrl entry points to the Lockserver
servlet.
# This Servlet is addressed by all distributed JVMs if
the RemoteLockMapImpl
# is used.
LockServletUrl=http://127.0.0.1:8080/ojb-lockserver
#
#
# The LockAssociations entry defines the behaviour for
the OJB
# implicit locking feature. If set to WRITE (default)
acquiring a write-
# lock on a given object x implies write locks on all
objects associated
# to x. If set to READ implicit read-locks are
acquired.
# Acquiring a read-lock on x thus allways results in
implicit read-locks
# on all associated objects.
#LockAssociations=READ
LockAssociations=WRITE
#
#
#----------------------------------------------------------------------------------------
# OQL / SQL settings
#----------------------------------------------------------------------------------------
# The OqlCollectionClass entry defines the collection
type returned
# from OQL queries. By default this value is set to
DListImpl.
# This will be good for most situations as DList
allows maximum flexibility
# in a ODMG environment. See also section 'ODMG
settings'.
# Using DLists for large resultsets may be bad for
application performance.
# For these scenarios you can use ArrayLists or
Vectors.
# Important note: the collections class to be used
MUST implement the
# interface
org.apache.ojb.broker.ManageableCollection.
#
OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2
#
OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
#
OqlCollectionClass=org.apache.ojb.broker.util.ManageableVector
#
# The SqlInLimit entry limits the number of values in
IN-sql statement,
# -1 for no limits. This hint is used in Criteria.
SqlInLimit=200
#
#
#----------------------------------------------------------------------------------------
# ODMG settings
#----------------------------------------------------------------------------------------
# Specify the used base class for ODMG API
# - ImplementationDefaultImpl is the default class
# - ImplementationJTAImpl is for use in managed
environments like J2EE conform
# Application Server
#
#ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
ImplementationClass=org.apache.ojb.odmg.ImplementationJTAImpl
#
#
# Specify the used tx handling.
# - LocalTxManager use if you want the transaction to
be associated by a thread
# - JTATxManager use if you want the transaction to be
associated via the Transaction
# manager that is in your application server.
#
#OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
OJBTxManagerClass=org.apache.ojb.odmg.JTATxManager
#
#
# Used ODMG collection implementation classes
# (e.g. when do a Implementation#newDlist() call)
#
# org.odmg.DList implementation class
DListClass=org.apache.ojb.odmg.collections.DListImpl_2
#DListClass=org.apache.ojb.odmg.collections.DListImpl
#
# org.odmg.DArray implementation class
DArrayClass=org.apache.ojb.odmg.collections.DListImpl_2
#DArrayClass=org.apache.ojb.odmg.collections.DListImpl
#
# org.odmg.DMap implementation class
DMapClass=org.apache.ojb.odmg.collections.DMapImpl
#
# org.odmg.DBag implementation class
DBagClass=org.apache.ojb.odmg.collections.DBagImpl
#
# org.odmg.DSet implementation class
DSetClass=org.apache.ojb.odmg.collections.DSetImpl
#
#
#----------------------------------------------------------------------------------------
# Meta data / mapping settings
#----------------------------------------------------------------------------------------
# The PersistentFieldClass property defines the
implementation class
# for PersistentField attributes used in the OJB
MetaData layer.
# By default the best performing attribute/refection
based implementation
# is selected (PersistentFieldDirectAccessImpl).
#
# - PersistentFieldDirectAccessImpl
# is a high-speed version of the access strategies.
# It does not cooperate with an AccessController,
# but accesses the fields directly. Persistent
# attributes don't need getters and setters
# and don't have to be declared public or protected
# - PersistentFieldPrivilegedImpl
# Same as above, but does cooperate with
AccessController and do not
# suppress the java language access check.
# - PersistentFieldIntrospectorImpl
# uses JavaBeans compliant calls only to access
persistent attributes.
# No Reflection is needed. But for each attribute
xxx there must be
# public getXxx() and setXxx() methods.
# - PersistentFieldDynaBeanAccessImpl
# implementation used to access a property from a
# org.apache.commons.beanutils.DynaBean.
# - PersistentFieldAutoProxyImpl
# for each field determines upon first access how to
access this particular field
# (directly, as a bean, as a dyna bean) and then
uses that strategy
#
PersistentFieldClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistentFieldIntrospectorImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanAccessImpl
#PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl
#
#
#----------------------------------------------------------------------------------------
# Component Intercepting for Profiling and Tracing
#----------------------------------------------------------------------------------------
# By enabling an InterceptorClass all OJB components
will use
# this Interceptor. Interceptors allow advanced
tracing and Profiling
# of all component method calls.
# This is currently an experimental feature useful
only for OJB kernel developers.
#
#InterceptorClass=org.apache.ojb.broker.util.interceptor.TracingInterceptor
#
#----------------------------------------------------------------------------------------
# Transaction Management and assocation
#----------------------------------------------------------------------------------------
# (optional, only used when OJB runs within managed
environments)
# To praticipate in JTA transaction OJB needs access
to the underlying transaction manager.
# The TransactionManager is acquired in different ways
dependent on the application server.
# The JTATransactionManagerClass property allows you
to specify the class that implements
# the proper behaviour for finding the transaction
manager. Only use when OJBTxManagerClass
# is set to a factory that uses the application server
transaction manager
# (org.apache.ojb.odmg.JTATxManager)
#
#JTATransactionManagerClass=edu.mayo.evolution.infrastructure.ojb.tx.OjbTransactionManagerFactory
JTATransactionManagerClass=edu.mayo.evolution.infrastructure.ojb.WebSphere5TransactionManagerFactory
# JBoss Transaction Manager Factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
# Weblogic Transaction Manager Factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WeblogicTransactionManagerFactory
# WebSphere transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WebSphereTransactionManagerFactory
# Orion transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.OrionTransactionManagerFactory
# SunOne transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.SunOneTransactionManagerFactory
# JOnAs transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JOnASTransactionManagerFactory
#
#
#----------------------------------------------------------------------------------------
# Logging settings are now in their own file,
OJB-logging.properties
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# End of OJB.properties file
#----------------------------------------------------------------------------------------
--- Armin Waibel <ar...@apache.org> wrote:
> Hi Gary,
>
> Gary wrote:
>
> > I am now getting the following warnings in a JTA
> > environment (this worked fine, no messages, before
> > RC7):
> >
> > 2004-06-15 13:32:26,728 WARN
> > [Servlet.Engine.Transports : 0] No running tx
> found,
> > please only delete objects in context of an
> > PB-transaction, to avoid side-effects - e.g. when
> > rollback of complex objects
> >
>
(org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java))
> >
> >
> > Looking into the code, it appears as though I am
> now
> > required to do a pb.beginTransaction() in even a
> > managed environment. Am I missing something?
> >
>
> I assume you use PB-api in managed environment and
> when deleting an
> object you use a JTA-tx?
>
> Did you set
>
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
> in OJB.properties (introduced in rc6)?
>
> regards,
> Armin
>
> > Thanks for all your hard work, Gary
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail is new and improved - Check it out!
> > http://promotions.yahoo.com/new_mail
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail:
> ojb-user-help@db.apache.org
> >
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail:
> ojb-user-help@db.apache.org
>
>
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: New Warnings in Managed Environment with RC7
Posted by Armin Waibel <ar...@apache.org>.
Hi Gary,
Gary wrote:
> I am now getting the following warnings in a JTA
> environment (this worked fine, no messages, before
> RC7):
>
> 2004-06-15 13:32:26,728 WARN
> [Servlet.Engine.Transports : 0] No running tx found,
> please only delete objects in context of an
> PB-transaction, to avoid side-effects - e.g. when
> rollback of complex objects
> (org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java))
>
>
> Looking into the code, it appears as though I am now
> required to do a pb.beginTransaction() in even a
> managed environment. Am I missing something?
>
I assume you use PB-api in managed environment and when deleting an
object you use a JTA-tx?
Did you set
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
in OJB.properties (introduced in rc6)?
regards,
Armin
> Thanks for all your hard work, Gary
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org