-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: Transaction Concurrency issue
PostPosted: Mon Jan 04, 2010 7:15 am 
Newbie

Joined: Mon Jan 04, 2010 7:00 am
Posts: 1
Hi everyone,

Happy New Year to all.

I am facing concurrency issues in my Web App and I used hibernate version to fix it.
It fixed the problem but then application is considerably slowing down to the extent of beoming non-responsive. We have restart the server to fix it.
We have checked the memory consumption, db connection pooling and db locks, everything seems normal but still it becomes non-resposive once or twice evryday.
If I remove the version thing then system is okay but concurrency issue occurs.

Code is as follows:

Code:
<class entity-name="balance" optimistic-lock="version" dynamic-insert="true" dynamic-update="true">
<composite-id>
<key-many-to-one lazy="false" name="walletId" entity-name="mtx_wallet"
            column="wallet_id"></key-many-to-one>
</composite-id>
<version name="modifiedOn" access="field" column="modified_on" type="timestamp">        </version>


Technologies used - Spring, Struts 2 , Hibernate with maps
Servers - Webshpere 6.1 and Oracle 10g

Please help me, this is a financial app and I feeling a lot of pressure from my manager.

Regards,
Rajiv


Top
 Profile  
 
 Post subject: Re: Transaction Concurrency issue
PostPosted: Fri Jan 08, 2010 9:30 am 
Newbie

Joined: Tue Jun 02, 2009 4:06 am
Posts: 16
Hi,

I havent tried this before but still i would ask you to refer to the section 11.3.2 and 11.3.3 mentioned in the below link where you can achieve concurrency by using session.saveOUpdate() OR session.flush().You dont have to use optimistic-lock in your mapping attribute if you use either of the option(session.saveORUpdate() OR session.flush()) in your code.

http://docs.jboss.org/hibernate/core/3. ... tions.html

I somehow feel that using optimistic-lock in the Class level is actually locking the entire row in the database which is why it is expensive and it is locking that object till the time it is bounded to the Hibernate Session.But if you use the above two options it will lock the database only when it is actually saving the data in the database and locking time will be reduced by this therby enhancing the scalabality of the application.

Its just my view but you could try doing this and please do let me know your results

-Kartik


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.