-
1. Re: How to disable disk writing when querying an external da
jhalliday Mar 19, 2009 2:40 PM (in response to roberto_france)Unfortunately you can't have your cake and eat it. Because you are using transactional connections, the transaction manager is doing log writes to provide you with transactional guarantees. So either: you don't actually need the transactional semantics, in which case your app is either misdesigned or misconfigured (try no-tx-datasource). Or you do need transactional semantics, in which case it's time to buy a faster disk. The new OCZ Z-Drive looks nice...
-
2. Re: How to disable disk writing when querying an external da
roberto_france Mar 19, 2009 6:08 PM (in response to roberto_france)Thank you jhalliday, I knew that it was a transactional related behavior and I just noticed that I'm currently using a local-tx-datasource instead of a no-tx-datasource as you rightly suggested.
Please correct the following reasoning of mine:
I only need transactions for failure recovery and very important things, such as if I want to periodically update an external db with the remaining credit of a telco user or similar, right? But if I need only to access data through a simple SELECT or a Hibernate's getSomething(), can I use the no-tx-datasource too or am I wrong?
If I have a complex business logic that needs both dummy queries and complex and periodic updates can I access the db in no-tx and xa mode using the same connector? For example can I write in mysql-ds.xml two sections, one <no-tx-transaction> and one <xa-resource> and access the same DB with the same connector in 2 different ways depending on the business logic that I implement?
Thanks for your time, I hope you can understand my far from perfect english!
Roberto -
3. Re: How to disable disk writing when querying an external da
marklittle Mar 20, 2009 6:53 AM (in response to roberto_france)There are some good papers on the JBossTS labs page (check the links down the left hand side) that discuss why you want to use transactions and when you maybe don't. Then there are also some very good books available on Amazon.
-
4. Re: How to disable disk writing when querying an external da
mmusgrov Mar 20, 2009 7:23 AM (in response to roberto_france)But if I need only to access data through a simple SELECT or a Hibernate's getSomething(), can I use the no-tx-datasource too or am I wrong?
You don't need to do anything special with readonly operations. If a resource manager returns readonly when asked to prepare then JBossTS will not create a log record i.e. it won't touch the disk. -
5. Re: How to disable disk writing when querying an external da
roberto_france Mar 20, 2009 7:48 AM (in response to roberto_france)"mmusgrov" wrote:
But if I need only to access data through a simple SELECT or a Hibernate's getSomething(), can I use the no-tx-datasource too or am I wrong?
You don't need to do anything special with readonly operations. If a resource manager returns readonly when asked to prepare then JBossTS will not create a log record i.e. it won't touch the disk.
That sounds reasonable but actually I'm having the same disk writing process and speed even if I'm using all SELECT or find() through Hibernate.
How can I set the resource manager to return read only responses? Now I'm using the <no-tx-datasource> to avoid the TM writing on the disk but it would be very good to have the TM to automatically choose to write or not the transactions depending on the type of action (query) passed to the DB. -
6. Re: How to disable disk writing when querying an external da
mmusgrov Mar 20, 2009 7:52 AM (in response to roberto_france)That sounds reasonable but actually I'm having the same disk writing process and speed even if I'm using all SELECT or find() through Hibernate.
I find that surprising - I will run it through the debugger towards the back end of next week to see why it would still be writing log records. -
7. Re: How to disable disk writing when querying an external da
marklittle Mar 20, 2009 8:01 AM (in response to roberto_france)
That sounds reasonable but actually I'm having the same disk writing process and speed even if I'm using all SELECT or find() through Hibernate.
Have you got any other resource managers in your application (including JMS, or JCA based)? -
8. Re: How to disable disk writing when querying an external da
roberto_france Mar 20, 2009 8:17 AM (in response to roberto_france)"mark.little@jboss.com" wrote:
Have you got any other resource managers in your application (including JMS, or JCA based)?
None that I know of, I simply have the default JBOSS directory with mobicents and my service running. I tried to use the null-persistence-service for JMS but the disk was always writing at the same speed.
The only way I found to stop that is to use a no-tx-datasource.
Is the TM supposed to write or not on the disk depending on the type of operation passed to the DB? -
9. Re: How to disable disk writing when querying an external da
marklittle Mar 20, 2009 10:50 AM (in response to roberto_france)As Michael mentioned above, if you're only doing read-only operations then the XAResource associated with your datasource should return read-only from prepare and the TM will not hit the disk unless there's another participant in the transaction that says it did some work that needs to be atomically updated.
-
10. Re: How to disable disk writing when querying an external da
roberto_france Mar 23, 2009 7:32 AM (in response to roberto_france)I am doing this with the JDBC connector/J for MySQL 5.1 :
conn = ds.getConnection(); PreparedStatement ps = conn.prepareStatement( "SELECT policy FROM services WHERE inbound_precode = ?" ); try { ps.setString(1, precode); ResultSet rs = ps.executeQuery(); }
I suppose this a read-only operation but I'm still having the disk writing, this happens with the XA and the local-tx datasource definition and the same using Persistence instead of the SQL query.
As I said before the only to way to stop it seems to use the <no-tx-datasource> but I lose all the transaction's behavior.
mmusgrov did you test anything this weekend? Maybe you can find out more about this issue.