openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: Cannot get QueryTimeout to work
Date Thu, 22 Mar 2007 23:52:09 GMT
I don't know what behavior to expect out of JDBC drivers outside of a
transaction.

Regarding avoiding transactions: in most situations, you should not see
any significant performance penalties for using transactions with
OpenJPA. The authors of Pro EJB3 are all Oracle employees, so maybe
there is something in their implementation that adds non-trivial
overhead to transactions.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Don Brady [mailto:dbrady@pobox.com] 
> Sent: Thursday, March 22, 2007 4:48 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Cannot get QueryTimeout to work
> 
> Hi,
> 
>   I hope this is not off-topic on this list, but I cannot seem to get 
> QueryTimeout to work, using the persistence.xml below under WebSphere 
> 6.1 with a DB2 connection pool defined in WebSphere, under 
> OpenJPA 0.9.6.
> 
>   It seems to just ignore the timeout specified and run to 
> completion no 
> longer how long it takes.
> 
>   I was wondering if the below should work or if there is 
> another way of 
> setting a query timeout.  I cannot find one.
> 
>   Actually if I wrap it in a transaction, then I can set a timeout on 
> the transaction and that does work.   But I was avoiding using a 
> transaction on the basis of advice in the book "Pro EJB" to omit 
> transactions if they are not needed, in the case of a 
> read-only query, 
> because they may incur a performance penalty.  Would that be true in 
> OpenJPA for a large read-only query or should I just use a 
> transaction 
> and set the timeout on that?
> 
>   Thank you for any comments!
> 
>   Don
> 
> 
> persistence.xml contents:
> 
>   <?xml version="1.0" encoding="UTF-8"?>
> <persistence version="1.0"
> 	xmlns="http://java.sun.com/xml/ns/persistence"
> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence 
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
> 
> 	<persistence-unit name="mpu-prod" transaction-type="JTA">
> 		<provider>
> 			
> org.apache.openjpa.persistence.PersistenceProviderImpl
> 		</provider>
> 		<jta-data-source>jdbc/mship-prod</jta-data-source>
> 		
> <non-jta-data-source>jdbc/mship-prod</non-jta-data-source>		
> 		
> <mapping-file>META-INF/orm-prod.xml</mapping-file>		
> 		
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> 	
> 		<properties>
> 		      <property name="openjpa.jdbc.Schema" 
> value="PROD" />
> 			<property name="openjpa.DataCache" 
> value="false" />
> 			<property 
> name="openjpa.RemoteCommitProvider" value="sjvm" />
> 			<property name="openjpa.Log"
> 				value="DefaultLevel=WARN, 
> Runtime=INFO, Tool=INFO, SQL=TRACE" />
> 			<property name="openjpa.jdbc.DBDictionary"
> 				
> value="db2(StoreCharsAsNumbers=false)" />
> 			<property 
> name="openjpa.TransactionMode" value="managed" />
> 			<property 
> name="openjpa.jdbc.TransactionIsolation"
> 				value="read-committed" />
> 			<property name="openjpa.ConnectionFactoryMode"
> 				value="managed" />
> 			<property 
> name="openjpa.ConnectionFactoryProperties" 
> value="QueryTimeout=30"/>
> 				
> 	
> 		</properties>
> 	</persistence-unit>
> 
> 	</persistence>
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message