How to disable disk writing when querying an external databa

[roberto_france]

Hello I'm developing SIP based services using JBOSS server 4.2.3 and Mobicents SLEE server 1.2.2 GA. Lately I found out that the services that make use of external DB queries cause the server's hard disk to write a lot.

Using the tool pidstat I have 1700KB/s written by the JBOSS process with an average of 36 query/s and 3400KB/s with an average of 90 query/s.
The disk is always writing inside the folder %JBOSS-SERVER%/data/tx-object-store/HashedActionStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/#xxx# ; where xx is a number between 0 and 254.

I tried with different services logic that doesn't use DB and I excluded Mobicents as the cause of the problem; so it must be the DB access. Of course the DB is on a remote machine and not on the JBOSS one.

I tried changing the connector/J for MySQL, tried XA and non XA connectors, tried with the NULL PERSISTENCE MANAGER for JMS but nothing. I'm always stuck with that disk writing operation going on...

I was using Hibernate to access the DB and I changed to JDBC statements and prepared statements but I always suffer from the same disk writing operation.

Do you know how can I disable it? I don't want the hd to compromise the overall performance and I would like to know how can someone disable the Jboss Transaction Manager that keeps writing db transactions on the disk.

[jhalliday]

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...

[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

[marklittle]

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.

[mmusgrov]

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.

[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.

[mmusgrov]

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.

[marklittle]

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)?

[roberto_france]

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?

[marklittle]

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.

[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.