The problem with all these 'tricks' to avoid synchronization is that they
rely on all sorts of assumptions about both the compiler and the underlying
memory model. Unfortunately the JVM spec is such that you really can't make
these assumptions.
See
Bugs item #582198, was opened at 2002-07-16 12:15
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=582198group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Pöschmann (thpoe)
Assigned to:
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
Hi,
I have just upgraded the tools/lib ant jars to be the released
version of 1.5 - the beta2 version has a bug with sending emails...
So - hopefull- semi-normal testing results will resume tomorrow...
Maybe I should try using an ibm jdk again...
Chris
=
Number of tests run: 655
Successful tests: 649
Errors:6
Failures: 0
[time of test: 18 July 2002 0:48 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
The problem with all these 'tricks' to avoid synchronization
is that they
rely on all sorts of assumptions about both the compiler and
the underlying
memory model. Unfortunately the JVM spec is such that you
really can't make
these assumptions.
See
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
But this isn't related to the problem. This code is trying to protect
against a stale volatile reference occuring between the initial comparison
and the access, it is not saying that the object being referenced is
thread safe. It is still the responsibility of the txCapsule object
to
The code is structured this way (catching NPE's) to avoid
synchronization as
stated in the comment in the code. If all the methods in
TransactionImpl were
synchronized there would be no problem, apart from the
performance. Whether
txCapsule is synchronized is irrelevant.
No, the code
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
On Thu, Jul 18, 2002 at 12:24:50PM +0100, Kevin Conner wrote:
The code is structured this way (catching NPE's) to avoid
synchronization as
stated in the comment in the code. If all the methods in
TransactionImpl were
synchronized there would be no problem, apart from the
Quick question for you Java Language Gurus out there, I heard one that the
post increment operator was an atomic operation. For example, if you have a
multi-threaded application with:
id=lastRequestId++;
You would not need to put this in a synchronized block be cause the ++ would
be
If lastRequestId is a long, then it clearly is not.
I don't think that it is in general either...not sure
if that changes with hotspot. And while it may be
under certain VMs, I don't think that you can generalize
that.
Brian
Original Message Follows
From: Hiram Chirino [EMAIL
OK, the fact that TxCapsule is thread-safe *is* important in
the overall
scheme of things, but for the purpose of this argument, 'Is
there a better
way than catching the NPE's it's not'
It is relevant only because you cited the double checked
locking. My point was that this problem had
I'm fairly sure that the increment/decrement operators are not atomic.
Hm...here's a post on Jguru showing why:
http://www.jguru.com/forums/view.jsp?EID=384082
Additionally, I think the statement that you gave in your example would be non-atomic
anyway- even if an increment was atomic, you're
The jguru article is not accurate.
Given the code:
public class Test {
public int testInc(int x) {
x++;
return x;
}
public int testAdd(int x) {
x = x + 1;
return x;
}
}
This produces the following byte-code:
Method Test()
0 aload_0
1
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
You know...something seemed odd about it, but I was going to go with it anyway...I'm
still pretty sure that an increment operation is not atomic, but I can't be sure.
Regardless, the example statement given in the original post was something like:
x = y++;
And I'm almost 100% certain that's
You know...something seemed odd about it, but I was going to
go with it anyway...I'm still pretty sure that an increment
operation is not atomic, but I can't be sure.
Regardless, the example statement given in the original post
was something like:
x = y++;
And I'm almost 100%
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
Dain Sundstrom wrote:
Ole Husgaard wrote:
+ // Using the construct
+ // try {
+ // txCapsule.doSomething();
+ // } catch (NullPointerException ex) {
+ // throw new IllegalStateException(No transaction.);
+ // }
+ // may look like bad
Yep, but you cannot guarantee the source of the NPE. It is
feasible that the NPE could be generated by a problem in the
called methods and this code will hide that.
Ah ha! good point, and a reason to change IMHO.
It is not a trick, it is the correct use of volatile. The compilers
Maybe we should be a little more restrictive than JTA here,
and only allow reentrant calls to the transaction service
during the callouts when done on the same thread.
I think that would allow us to simply synchronize on the
methods of the TransactionImpl frontend.
The downside of
marc fleury wrote:
Maybe we should be a little more restrictive than JTA here,
and only allow reentrant calls to the transaction service
during the callouts when done on the same thread.
I think that would allow us to simply synchronize on the
methods of the TransactionImpl frontend.
The
Hiram,
I this code is at least 2 operations. Most of the atomic operations
(except int assignment) are completely useless because you can't both
invoke the operator and get the result in a single operation. For example:
a: increment i (i=1)
b: increment i (i=2)
a: assign i to out (out = 2)
Ah - you are correct. Here is the byte-code for the incrementor with a
member variable:
Method Test()
0 aload_0
1 invokespecial #1 Method java.lang.Object()
4 return
Method int testInc()
0 aload_0
1 dup
2 getfield #2 Field int x
5 iconst_1
6 iadd
7 putfield #2 Field
Kevin Conner wrote:
As an aside, having just looked at the 3.0.1 code (this may
have changed since then), commit, delistResource, enlistResource,
registerSynchronization, rollback and setRollbackOnly are protected
by the lock method (and hence synchronisation).
Until my recent commit, the
Kevin Conner wrote:
As an aside, having just looked at the 3.0.1 code (this may
have changed since then), commit, delistResource, enlistResource,
registerSynchronization, rollback and setRollbackOnly are protected
by the lock method (and hence synchronisation).
Until my recent commit,
Being a lazy programmer, I've always found that if I'm spending my few
remaining neurons trying to figure out what operation is truly atomic
and what isn't, I'll be better off designing the system in such a way
that it doesn't matter.
I've spent enough time grovelling through disassembled
Dain Sundstrom wrote:
marc fleury wrote:
The transaction concept in the web is one of synchronization of
different workers. The best example is JCA. If you limit the number of
threads that can be working in a TM at the same time you go back to the
one thread of control view of the
Ole Husgaard wrote:
There is a problem with holding on to a TxCapsule reference:
TxCapsule instances are relatively heavy-weight, and may be
reused to control other transactions.
How heavyweight? If you scrap the reuse code, what is the performance
impact?
I am trying to push the discussion
Bugs item #582198, was opened at 2002-07-16 12:15
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=582198group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Pöschmann (thpoe)
Assigned
Bugs item #583441, was opened at 2002-07-18 20:21
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=583441group_id=22866
Category: JBossMQ
Group: v3.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexey Loubyansky (loubyansky)
Assigned to:
Dain Sundstrom wrote:
Ole Husgaard wrote:
There is a problem with holding on to a TxCapsule reference:
TxCapsule instances are relatively heavy-weight, and may be
reused to control other transactions.
How heavyweight? If you scrap the reuse code, what is the performance
impact?
Not
Bugs item #575815, was opened at 2002-06-30 22:57
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=575815group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to:
Number of tests run: 669
Successful tests: 664
Errors:5
Failures: 0
[time of test: 18 July 2002 12:32 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
Bugs item #583441, was opened at 2002-07-18 10:21
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=583441group_id=22866
Category: JBossMQ
Group: v3.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexey Loubyansky (loubyansky)
Assigned to:
I finally have Rice RUBiS code running my my server. I had to toss
their make based build system and I merged the web, servlet, and ejb
tier's into a single ear (all of these were on a single box). Later I
will update the ant script to support the running of these on different
tiers.
Bugs item #542365, was opened at 2002-04-11 00:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=542365group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Wont Fix
Priority: 9
Submitted By: Peter Luttrell (objec)
Assigned
FYI, I get these errors in one my applications as well, which is under heavy
load...
Still, all pages seem to be available normally despite getting this error.
From: Dain Sundstrom [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Thu, 18 Jul 2002 14:41:50 -0500
To: JBoss-dev [EMAIL
Ouch - that does not look good!
The java.lang.IllegalStateException: Not EDITABLE
exception is thrown when something tries to modify a request
when it is not in a modifiable state. This is normally when
the header has already been committed when sending the response.
However, you are
Greg Wilkins wrote:
Ouch - that does not look good!
The java.lang.IllegalStateException: Not EDITABLE
exception is thrown when something tries to modify a request
when it is not in a modifiable state. This is normally when
the header has already been committed when sending the
Greg Wilkins wrote:
Ouch - that does not look good!
The java.lang.IllegalStateException: Not EDITABLE
exception is thrown when something tries to modify a request
when it is not in a modifiable state. This is normally when
the header has already been committed when sending the
Automated JBoss(WonderLand) Testsuite Results: 19-July-2002\n\n
begin 644 TESTS-TestSuites.txt
MDYU;6)EB!O9B!T97-TR!R=6XZ( @.#0S@HM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0H*4W5C8V5SV9U;!T97-T
MSH@( @( X,3$*17)R;W)S.B @( @( @( @( @( R.0I86EL=7)E
MSH@( @( @( @(
Bugs item #542365, was opened at 2002-04-11 00:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=542365group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Wont Fix
Priority: 9
Submitted By: Peter Luttrell (objec)
Assigned
Bugs item #542365, was opened at 2002-04-11 00:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=542365group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Wont Fix
Priority: 9
Submitted By: Peter Luttrell (objec)
Assigned
I updated the source and I'm still getting errors on a very regular
basis. I don't think these are a problem for this test. Here are the
new stack traces:
20:24:10,394 WARN [jbossweb] WARNING: GET
/servlet/edu.rice.rubis.beans.servlets.ViewItem?itemId=1109 HTTP/1.1
Bugs item #583618, was opened at 2002-07-18 16:39
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=583618group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Lamar Channell (channell)
Assigned
Bugs item #583619, was opened at 2002-07-18 20:41
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=583619group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Black (rblack)
Assigned to:
Dear All,
According to the CSIRO report (http://www.cmis.csiro.au/adsat/jboss.htm), JBoss is
doing well with Stateless session beans. It implies reflection, by comparing to static
compiled codes, doesn't affect the performance much, while it has great architectural
advantages such as
Bugs item #580207, was opened at 2002-07-11 11:04
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=580207group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Gary Capps (gary_capps)
Assigned
54 matches
Mail list logo
