Two stuck threads in synchronized method - at least it seems likefrom a stack trace

[Greg Stasica]

hi,

from the stack trace it seems like there are two different threads in
synchronized method but how could it be possible ?

public class DBQuery{

private static DBQuery dbQuery = null;

public static DBQuery getInstance()
{
if (dbQuery == null) {
dbQuery = new DBQuery();
}
return dbQuery;
}

public synchronized void saveAuditVersion(boolean fIncrementVersion)
{
try{
doSQLStatement(sql); //line 332
}
catch(SQLException sqle){... }
finally { ...}

if(fIncrementVersion){
refData.setAuditVersion(refData.getAuditVersion()+1); //line 348
......
}

public static doSQLStatement(String sql){....}

}

Thread-159 "[STUCK] ExecuteThread: '12' for queue:
'weblogic.kernel.Default (self-tuning)'" <alive, in native,
priority=1, DAEMON> {
jrockit.net.SocketNativeIO.readBytesPinned(Native Method)
jrockit.net.SocketNativeIO.socketRead(Unknown Source)
java.net.SocketInputStream.socketRead0(SocketInputStream.java:???)
java.net.SocketInputStream.read(SocketInputStream.java:129)
oracle.net.ns.Packet.receive(Unknown Source)
oracle.net.ns.NSProtocol.connect(Unknown Source)
oracle.jdbc.ttc7.TTC7Protocol.connect(TTC7Protocol.java:1689)
oracle.jdbc.ttc7.TTC7Protocol.logon(TTC7Protocol.java:215)
^-- Holding lock: oracle.jdbc.ttc7.TTC7Protocol@295b96a[thin lock]
oracle.jdbc.driver.OracleConnection.<init>(OracleConnection.java:
360)

oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.java:
521)
oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:325)
java.sql.DriverManager.getConnection(Unknown Source)
^-- Holding lock: java.lang.Class@10266d9[recursive lock]
java.sql.DriverManager.getConnection(Unknown Source)
^-- Holding lock: java.lang.Class@10266d9[fat lock]

org.apache.commons.sql.util.DataSourceWrapper.getConnection(DataSourceWrapper.java:
117)
com.xx.util.DBConnection.connect(DBConnection.java:80)
com.xx.server.DBQuery.doSqlGetmultColumns(DBQuery.java:7242)
com.xx.server.DBQuery.doSqlGetmultColumns(DBQuery.java:7219)
com.xx.server.DBQuery.loadAuditVersion(DBQuery.java:275)
com.xx.RefData.getAuditVersion(RefData.java:394)
com.xx.server.DBQuery.saveAuditVersion(DBQuery.java:348)
^-- Holding lock: com.xx.DBQuery@d903876[fat lock]
com.xx.checkSchedule(TestAction.java:904)

Thread-160 "[STUCK] ExecuteThread: '13' for queue:
'weblogic.kernel.Default (self-tuning)'" <alive, in native,
priority=1, DAEMON> {
jrockit.net.SocketNativeIO.readBytesPinned(Native Method)
jrockit.net.SocketNativeIO.socketRead(Unknown Source)
java.net.SocketInputStream.socketRead0(SocketInputStream.java:???)
java.net.SocketInputStream.read(SocketInputStream.java:129)
oracle.net.ns.Packet.receive(Unknown Source)
oracle.net.ns.NSProtocol.connect(Unknown Source)
oracle.jdbc.ttc7.TTC7Protocol.connect(TTC7Protocol.java:1689)
oracle.jdbc.ttc7.TTC7Protocol.logon(TTC7Protocol.java:215)
^-- Holding lock: oracle.jdbc.ttc7.TTC7Protocol@10ea675f[thin lock]
oracle.jdbc.driver.OracleConnection.<init>(OracleConnection.java:
360)

oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.java:
521)
oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:325)
java.sql.DriverManager.getConnection(Unknown Source)
^-- Holding lock: java.lang.Class@10266d9[recursive lock]
java.sql.DriverManager.getConnection(Unknown Source)
^-- Holding lock: java.lang.Class@10266d9[fat lock]

org.apache.commons.sql.util.DataSourceWrapper.getConnection(DataSourceWrapper.java:
117)
com.xx.util.DBConnection.connect(DBConnection.java:80)
com.xx.server.DBQuery.doSQLStatement(DBQuery.java:7160)
com.xx.server.DBQuery.saveAuditVersion(DBQuery.java:332)
^-- Holding lock: com.xx.server.DBQuery@d903876[fat lock]
com.xx.checkSchedule(TestAction.java:904)

just to clarify:
DBQuery is although not thread-safe initialized singleton class.
DBConnection is an utility class with no synchronized methods.

As i understand from the stacktrace both threads reference the same
memory address and hold the lock
^-- Holding lock: com.xx.server.DBQuery@d903876[fat lock]
in such a case and excluding any calls to wait() (there is not any)
how is it possible that stack trace shows something as above?

 

[Neil Coffey]

public class DBQuery{

private static DBQuery dbQuery = null;

public static DBQuery getInstance()
{
if (dbQuery == null) {
dbQuery = new DBQuery();
}
return dbQuery;
}

You do know that this getInstance() method isn't thread-safe, don't you?

Neil

 

[Arne Vajhøj]

You do know that this getInstance() method isn't thread-safe, don't you?

At least he can get multiple DBQuery objects, but he should always
get a valid DBQuery reference back.

Arne

 

[Mike Schilling]

At least he can get multiple DBQuery objects, but he should always
get a valid DBQuery reference back.

I don't think that's guaranteed. There is some possibility that he'll
get a DBQuery that is not fully initialized, since the JVM is within
its rights to reorder the assignment to dbQuery with the statements in
the constructor. (Disclaimer; that was true in the original JVM
memory model. I don't know if the current one changes that.)

 

[Arne Vajhøj]

I don't think that's guaranteed. There is some possibility that he'll
get a DBQuery that is not fully initialized, since the JVM is within
its rights to reorder the assignment to dbQuery with the statements in
the constructor. (Disclaimer; that was true in the original JVM
memory model. I don't know if the current one changes that.)

I don't think the MM has changed regarding that.

And that could be a problem as well. Could be, because I don't
think we have seen the constructor.

Arne

 

[Neil Coffey]

I don't think that's guaranteed. There is some possibility that he'll
get a DBQuery that is not fully initialized, since the JVM is within
its rights to reorder the assignment to dbQuery with the statements in
the constructor. (Disclaimer; that was true in the original JVM
memory model. I don't know if the current one changes that.)

No, it doesn't -- au contraire, as time moves on we'll probably see more
VMs implementing such optimisation.

It's hard to say if this was what actually caused the anomaly the
poster reported -- I have to admit you'd be extremely unlucky (but
then out in the wild, the extremely unlikely does eventually occur...).
It *is* a bug, so in absence of anything else to go on, I'd
recommend correcting it as the first course of action.

Neil

 

[edmund yau]

Neil Coffey æ到:

No, it doesn't -- au contraire, as time moves on we'll probably see more
VMs implementing such optimisation.

It's hard to say if this was what actually caused the anomaly the
poster reported -- I have to admit you'd be extremely unlucky (but
then out in the wild, the extremely unlikely does eventually occur...).
It *is* a bug, so in absence of anything else to go on, I'd
recommend correcting it as the first course of action.

Neil

IT manager 蛇頭鼠眼edmund yau (email擬似[email protected])
全香港最濺IT Manager, 見你著西è£è¿”å·¥. 著得好éŽä½¢å°±å•ä½ å¤ ç«Ÿé»žè«—, æ­£å°äºº,
ç—´æ’šç·š
5:00pm俾個jobä½ åš, è·Ÿä½å°±è‡ªå·±åšåˆ°11點æžæŽ‚ä½¢, 第2日就å°ä½ , 話你æžå””掂, å””
撚洗放工呀

最撚柒就係呢æ¢å‹å•¦, æžå€‹çˆ›ç¶²å‡ºé»Ž, 大家去ç‡ä¸‹:
網å€æ“¬ä¼¼www.funzy.com

有幾爛? 仆街, 用IE6開會死機架, 真係唔撚知用乜野skillå¯ä»¥å¯«æ’šåˆ°hangæ©Ÿ.

æˆæ¢teamæœ9晚10, æžå€‹çˆ›ç¶²å¾—個2個functionä»”, 唔係hang機就係死link, 仲話寫
webè¦éƒ½å””知乜撚野skill set, 食屎啦, å°å­¸ç”Ÿå¯«å€‹web都唔撚會hang機啦

個個åŒäº‹æƒ³æ”¾å·¥éƒ½è¦é©šå‘¢æ¨£é©šå€‹æ¨£, 你張你oçš„é’春濺賣就唔撚好å«äººä¸€é½ŠåŒä½ æ¿º
è³£, 人地都有屋ä¼, 你唔撚放工就你o既事, 除撚左打工都唔撚知æžå€‹web未, 屎å‘關刀

大家多多張呢個網發佈出去, è²è¨Žå‘¢ç¨®å°äºº



Counter
1