6:13 p.m.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2, MicroContainer bus
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Assigned To: Alexey Loubyansky
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx). It
seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:45 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=comments#action_12414826 ]
Adrian Brock commented on JBAS-5564:
------------------------------------
The code looks correct to me.
Let me take it apart... :-)
if (
// If some thread is already invoking on the instance
lockHolder != null)
if (
// And it's not our thread
lockHolder != curThread && (
// There's no transaction so there can be no transactional lock
miTx == null ||
// Or it's some other thread in the same transaction
miTx.equals(holdingTx)))
Then we check for deadlocks and wait...
Your suggestion would only occur if the BeanLock has failed.
i.e. some other thread is invoking on the same shared instance in a different transaction
That should not be possible with a shared cache and a proper lock doing its processing
before this code even runs.
The re-entrance processing is not intended to handle the real (transactional) lock, its
main
purpose is to handle concurrent/recursive invocations outside a transaction or in the
(technically against spec)
two threads with the same transaction.
So my conclusion is that at least one of the following is true:
1) This statement is incorrect:
"I use an own implementation of a BeanLock, which is so far correct an not an issue
in this ticket"
2) You didn't read the FAQ referenced from JBAS-4177
http://wiki.jboss.org/wiki/ChangingTheLockingPolicy
i.e. your custom bean lock is not appropriate for a shared instance cache
3) You have some other issue such as the entity bean's primary key class not
implementing
equals/hashCode() correctly so the cache is handing out the wrong instances
If you want help with your BeanLock use the forums not a bug report.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: MicroContainer bus, EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Assigned To: Alexey Loubyansky
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:47 p.m.
New subject: [JBoss JIRA] Updated: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=all ]
Adrian Brock updated JBAS-5564:
-------------------------------
Component/s: (was: MicroContainer bus)
Affects Version/s: (was: JBossAS-5.0.0.Beta3)
Assignee: (was: Alexey Loubyansky)
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:47 p.m.
New subject: [JBoss JIRA] Updated: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=all ]
Adrian Brock updated JBAS-5564:
-------------------------------
Affects: (was: [Compatibility/Configuration])
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:47 p.m.
New subject: [JBoss JIRA] Closed: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=all ]
Adrian Brock closed JBAS-5564.
------------------------------
Resolution: Rejected
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:34 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=comments#action_12414961 ]
Domagoj Cosic commented on JBAS-5564:
-------------------------------------
1) This statement is incorrect:
"I use an own implementation of a BeanLock, which is so far correct an not an issue
in this ticket"
Not an issue here, but I will give a short description here: It is a single write,
multiple read lock, which is a enhancement of SimpleReadWriteLock supplied with JBoss. My
lock is transactional and queued and guarantees READ_COMMITED policy.
I did not state that my current problem is actually caused by NonReentrantLock, but the
code of NonReentrantLock looked strange to me. What is the purpose of NonReentrantLock for
re-entrant Entity Beans anyway? Is there a document about this issue?
2) You didn't read the FAQ referenced from JBAS-4177
http://wiki.jboss.org/wiki/ChangingTheLockingPolicy
i.e. your custom bean lock is not appropriate for a shared instance cache
Actually I did read it before commiting the ticket.
3) You have some other issue such as the entity bean's primary
key class not implementing
equals/hashCode() correctly so the cache is handing out the wrong instances
My bean's Primary Key class is java.lang.String.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:36 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=comments#action_12414962 ]
Domagoj Cosic commented on JBAS-5564:
-------------------------------------
Contrary to my earlier statement, there is no easy workaround possible.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:20 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=comments#action_12414969 ]
Domagoj Cosic commented on JBAS-5564:
-------------------------------------
I tracked down my problem now. The beforementioned logical expression in NonReentrantLock
may be O.K., it does not bother me anyway. My problem is:
miTx is null although I have a transaction.
miTx is not mi transaction at all! Is it intended? In EntityReentranceInterceptor, you
read the transaction from EntityEnterpriseContext, not from MethodInvocation, hence the
name is misleading. Transaction in EntityEnterpriseContext is normaly set in
EntityInstanceInterceptor (to the value from MethodInvocation), but not for read only
methods. I have a read only method in this case! Is it correct that the transaction is
null in that case?
To conclude: If two threads access a bean in read only manner simultaneosly (which they
are allowed to), the second one lands in wait with no necessity. If I make my bean non
re-entrant, such a problem does not occur. It cannot be that the logic is different for
re-entrant an non re-entrant beans.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:22 a.m.
New subject: [JBoss JIRA] Reopened: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=all ]
Domagoj Cosic reopened JBAS-5564:
---------------------------------
The problem is probably in EntityReentranceInterceptor but the conversation about the
problem is completely in this ticket, so I re-open the ticket.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:24 a.m.
New subject: [JBoss JIRA] Updated: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=all ]
Domagoj Cosic updated JBAS-5564:
--------------------------------
Workaround Description: (was: Compiling a version of this class with line 143
changed. Compiling a version of EntityReentranceInterceptor that uses the new class.
Changing standardjboss.xml or jboss.xml to use the new EntityReentranceInterceptor. )
Workaround: (was: [Workaround Exists])
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:45 p.m.
New subject: [JBoss JIRA] Closed: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=all ]
Adrian Brock closed JBAS-5564.
------------------------------
Resolution: Rejected
"It is a single write, multiple read lock"
You can't do that. EJB instances cannot be invoked upon in multiple threads
concurrently,
it breaks their contract. See the EJB spec.
Concurrent invocations on the same entity requires instance-per-transaction
configurations
as per the FAQ.
"The problem is probably in EntityReentranceInterceptor but the conversation about
the problem is completely in this ticket, so I re-open the ticket."
Conversations/questions belong in the forums not bug reports.
Please don't open this again.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:13 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=comments#action_12414997 ]
Domagoj Cosic commented on JBAS-5564:
-------------------------------------
Then there is no point at all in JBoss providing read only beans and methods!
Now I will follow your advice and transfer this whole thing to the forum. Sorry for
annoyance.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:26 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=comments#action_12415000 ]
Adrian Brock commented on JBAS-5564:
------------------------------------
"Then there is no point at all in JBoss providing read only beans and methods!"
Read only invocations still wait to avoid concurrent invocations,
they just don't wait until the transaction is complete like a normal transactional
lock.
That's because they don't have to check whether the bean needs storing back to the
database
(at the end of the transaction) because its state doesn't change.
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:35 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5564) Probable logical problem in NonReentrantLock
[ http://jira.jboss.com/jira/browse/JBAS-5564?page=comments#action_12415002 ]
Domagoj Cosic commented on JBAS-5564:
-------------------------------------
... so a bean lock has to prevent concurrent method execution within a bean even for a
read access, as opposed to preventing concurrent execution within the whole transaction,
when an write access is involved.
(will not be continued)
Probable logical problem in NonReentrantLock
--------------------------------------------
Key: JBAS-5564
URL: http://jira.jboss.com/jira/browse/JBAS-5564
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA
Environment: None, source code analysis
Reporter: Domagoj Cosic
Introduction: My direct problem is distantly related to JBAS-4177. The difference is, I
use an own implementation of a BeanLock, which is so far correct an not an issue in this
ticket, nor is the my original problem that the NonReentrantLock causes. However, my
original problem led me to NonReentrantLock and I analyzed its source code in some depth.
I have a suspicion that there is a serious bug in it.
The problem I want to point at is in the line 143:
Up to the trunk revision there stands:
if(lockHolder != curThread && (miTx == null || miTx.equals(holdingTx)))
There is some contradiction to the description:
"It will throw a ReentranceException if the same thread tries to acquire twice
or the same transaction tries to acquire twice"
For a non re-entrant bean it means, in pseudo code:
if (sameThread or sameTransaction) {
throw new ReentrantException();
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
This description does not apply to an re-entrant bean, but for re-entrant bean it
basically means (in pseudo code):
if (sameThread or sameTransaction) {
return true;
} else {
waitForOtherThreadOrTransaction;
on timeout return false;
return true;
}
I backtracked the code to the previous change, which was revision 16662 dated 27.08.2003
There it stands:
if (lockHolder == Thread.currentThread()) throw new ReentranceException();
if (miTx != null && miTx.equals(holdingTx)) throw new
ReentranceException();
Although this code was for the non re-eantrant case, for the re-entrant case the code
should return true for those cases, where ReentrantException was thrown.
Let us transform this code step by step:
Step 1:
if (lockHolder == Thread.currentThread()) return true;
if (miTx != null && miTx.equals(holdingTx)) return true;
Step 2:
if (lockHolder == Thread.currentThread() || miTx != null &&
miTx.equals(holdingTx)) {
return true;
} else {
wait;
return true;
}
Step 3 (negating):
if (lockHolder != Thread.currentThread() && (miTx == null ||
!miTx.equals(holdingTx))) {
wait;
return true;
} else {
return true;
}
You see the difference? Current code lacks "!" before miTx.equals(holdingTx).
It seems wrong to me and it causes a problem for me, so it would be nice if someone else
takes a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5877
days inactive
5878
days old
13 comments
2 participants
participants (2)
-
Adrian Brock (JIRA) -
Domagoj Cosic (JIRA)