Folks,
I'm trying to figure out what the most efficient way to use castor to do OQL
queries within a j2ee server is (WL 6.1sp1). Most of the data that is
fetched is not modified during the course of a single transaction.
We currently invoke the following (pseudo) code to do our fetches.
- get transaction from app server transaction manager
- ut.begin()
- get jdo from JNDI
- jdo.getDatabase()
- query.execute()
- create collection of result objects
- ut.commit()
- db.close()
- return collection
The castor docs state that when using castor within a j2ee app server, use
user transactions to manage transactions.
Is there any way to execute OQL queries so they don't require an active
transaction? Something like an autocommit(true) mode (like you can do with
raw JDBC)? i.e. implicit transaction management without using EJBs.
Can we replace ut.begin() and ut.commit() with db.begin() and db.commit()
(i.e. don't incur the overhead of registering with the TM)? Are there any
bad side effects to doing this in a j2ee server? We don't need the app
server's TM to manage distributed transaction. After all most of this is
read-only data.
Since the data that is fetched is not modified within the same transaction
should we be setting the accessMode on the query.execute() to be read only?
query.execute((short)0) - Will that yield better performance?
Are there any other tweaks/changes that we can make to improve performance
for these fetches.
thanks.
-shehryar
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
