[marklittle]

If Hibernate uses the same transaction as the earlier JDBC operation, then (depending on the locking rules), it should inherit the same capabilities and be able to read the tables which are locked. But it would appear that is not happening. Can you confirm that the Hibernate insert is occurring in a new transaction?

[balellu]

Mark, Thanks for your reply.

JDBC uses READ_COMMITED isolation level for Hibernate this value is not set explicity, i guess it default is TRANSACTION_REPEATABLE_READ. I am not sure about this.

Looking at this i think though JDBC & Hibernate are in the same CMT they seem to be using different isolation levels. I will try to set the isolation level explicitly at hibernate end and i will update you later.

I have couple of questions.

1. If JDBC & Hibernate use same ISOALTION level will that solve the problem?

2. JDBC & Hibernate user different connects to connect to DB, still do you think same transaction ISOALTION will get inherited?

Thanks

[marklittle]

I think you're right in that the default isolation level for DB2 is to allow repeated reads. I'm not sure about DB2, but if this was Oracle then it would upgrade the REPEATABLE_READ to SERIALIZABLE. If you are using different connections between JDBC and Hibernate (which you are), then blocking could occur between different branches in the same transaction (that depends on the RM).

I think the best solution at this stage is to backup and see if there's any way you can write your application so it is portable across different RMs. Is there any way you could do this in two separate invocations, for example?

[balellu]

Mark, Thanks for the reply.

think the best solution at this stage is to backup and see if there's any way you can write your application so it is portable across different RMs. Is there any way you could do this in two separate invocations, for example?

This is a pre-implemented project and we are doing customizations and bug fixes so we cannot do major changes to the code.

What do you mean by RM?

Current versions of this code are running in websphere with the same code. I think websphere some how figures out that transaction context and provides the same connection object both to JDBC & Hibernate (the both use managed data source).

Our effort is to migrate to JBoss. Can we replicate this same behavior in JBoss, that is; is there a way where i can configure JBoss so that it gives same connection object to JDBC & Hibernate? Doing so will it solvce this deadlock issue?

Please note that we are invoking Hibernate Entity EJBs in RMI not as local, if moving local can solve this problem then we can move but that will again include lot of change.

Please let me know your comments.

Thanks

[marklittle]

"balellu" wrote:
Mark, Thanks for the reply.

think the best solution at this stage is to backup and see if there's any way you can write your application so it is portable across different RMs. Is there any way you could do this in two separate invocations, for example?

This is a pre-implemented project and we are doing customizations and bug fixes so we cannot do major changes to the code.

What do you mean by RM?

Resource Manager (database in this case).

Current versions of this code are running in websphere with the same code. I think websphere some how figures out that transaction context and provides the same connection object both to JDBC & Hibernate (the both use managed data source).

Our effort is to migrate to JBoss. Can we replicate this same behavior in JBoss, that is; is there a way where i can configure JBoss so that it gives same connection object to JDBC & Hibernate? Doing so will it solvce this deadlock issue?

I think you need to escalate this within the Hibernate forum then. It's certainly something that should be possible (it's not a limitation of transaction processing).

Please note that we are invoking Hibernate Entity EJBs in RMI not as local, if moving local can solve this problem then we can move but that will again include lot of change.

Please let me know your comments.

Thanks

Sorry I can't be of much help.

[balellu]

Mark,

Lets me drop hibernate & jdbc and just put down in terms of transaction. Could you confirm if what ever we are doing in the code is right?

That is in a CMT i am opening a connection and inserting data into a table and closing that connection, after a while in the same CMT method im trying to access the same table (just used in insert) by using a different connection object. Will this work?

That is in a CMT two connection objects are trying to access same table simultaneously. Let me know your comment

I have also noticed below information in the log file.

2006-08-09 19:17:29,850 WARN [org.jboss.resource.connectionmanager.TxConnectionManager] Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure

Thanks

[marklittle]

"balellu" wrote:
Mark,

Lets me drop hibernate & jdbc and just put down in terms of transaction. Could you confirm if what ever we are doing in the code is right?

That is in a CMT i am opening a connection and inserting data into a table and closing that connection, after a while in the same CMT method im trying to access the same table (just used in insert) by using a different connection object. Will this work?

Yes, as long as the work is in the scope of the same transaction it should work.

That is in a CMT two connection objects are trying to access same table simultaneously. Let me know your comment

I have also noticed below information in the log file.

2006-08-09 19:17:29,850 WARN [org.jboss.resource.connectionmanager.TxConnectionManager] Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure

Thanks

I assume you're getting JBossTS debugging still?

[balellu]

Yes, as long as the work is in the scope of the same transaction it should work.

Then why am i getting the deadlock?
Is there way i can test / check this behavior in JBoss?

I assume you're getting JBossTS debugging still?

Yes i am still getting the debug messages

Thanks.

[marklittle]

I don't know why you're getting the deadlock. I've given some ideas (maybe the isolation level settings, maybe the database, maybe Hibernate).

Can you duplicate the problem by taking out JBossTS and going back to the old transaction manager? If you can, then it may be easier to then post something to the hibernate forum and get a response.

[balellu]

Mark, Thanks for the reply.

Can you duplicate the problem by taking out JBossTS and going back to the old transaction manager? If you can, then it may be easier to then post something to the hibernate forum and get a response.

What do you mean by taking out JBossTS? Moving back to websphere and reproduce the problem? (we dont face this problem in websphere)

Is there a way we can monitor EJB container for transaction activities?

IF you can let me know it will be great.

I am going to take a deep look into DB2 and see if there is something of interest to us. In the next post i will tell you the types of locks that are held DB2 end, may be that will help.

Thanks.

[marklittle]

Sorry, my bad: I've been working on a couple of support queries and forget you don't use JBossTS - you're already using the old transaction manager.

[balellu]

Thanks a lot for clarification Mark.

Is there a way we can monitor EJB container for transaction activities?

Thanks

[marklittle]

I suggest attaching a debugger (e.g., Eclipse) to the running application server and stepping through that. You'll be able to see what it is doing and compare this to what you think it should be doing.

[balellu]

This problem is resolved. Application primarily uses two different data-sources . Connection obtained by hibernate was from different data-source than that of JDBC. I was able to figure this out after thoroughly debugging the app.

Both JDBC & Hibernate were using same JNDI name to lookup for the data-source but they were provided different data-sources by JBoss. When I dumped the JNDI tree of JBoss I understood real problem was the way RESOURCE-REF in ejb-jar.xml being linked to jboss.xml, for all entries of RESOURCE-REF in ejb-jar.xml they were all being linked to a data-source, this means that all my entity beans use a different DS than that of JDBC. So I created a new RESOURCE-MANAGER in jboss.xml to include DFS used by JDBC and linked the entire ENTITY bean RESOURCE-REF in ejb-jar.xml to it.

Mark, I would like to thank you for your continuous support and lightning quick responses when i need them.

Thanks

[marklittle]

Glad you found the problem. I hope I was some help, but am sorry we weren't able to resolve it sooner.