Home/ Questions/Q 6706721
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T07:33:14+00:00

I’ve had a working version of multi-threaded code, however I was unsatisfied with my

  • 0

I’ve had a working version of multi-threaded code, however I was unsatisfied with my PreparedStatement-wrapperclass being non-threadsafe. So I decided to generate the PreparedStatements in a ThreadLocal to make the wrapper threadsafe.

Immediately the SQLExceptions startet to hail down on me. The underlying Oracle-error is an ORA-00060 deadlock detected which should – according to the internet – only occur in write scenarios. My statements are all read-only. It occurs in some obscure ACL-package which I’ve neither heard of nor accessed consciously.

I’ve with some time and effort prepared and tested a hypothesis which is, generating a Connection object and preparing a statement from that Object from a DataSource object should not occur at the very same time because the access control of the database might not be “threadsafe” (althoug DataSource most certainly is). Can someone confirm or deny that finding?

If this is indeed the case, is there a best-practise how to avoid that PreparedStatements are generated at the very same time in a multithreaded application?

EDIT: As asked the text of the exception:

Caused by: java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-00060: deadlock detected while waiting for resource
ORA-06512: at "XXX.PKG_ACL", line 129
ORA-06512: at "XXX.PKG_ACL", line 459
ORA-06512: at "XXX.PKG_UTILS", line 1933
ORA-06512: at line 6
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Can someone confirm or deny that finding?

    I haven’t heard anything along those lines, and if it does exist, it might purely be an implementation detail. Can you post your stack trace (by stripping personal info of course)?

    Also, any reason why you are trying to make PreparedStatement thread safe rather than relying on the prepared-statement pool/cache? Or more specifically, what kind of analysis drives you to implement a ThreadLocal PreparedStatement?

    • 0