Re: [JBoss-user] LOCKING-WAITING (CTX)
Hi, this is standard ejb behavior, the Bean gets locked if it is accessed, since on BMP the app-server never knows what you are going to do, right (there is no reson why you shouldn't do some update-statement when reading a value, right?!? So go ahead and read the long and most entertaining discussion on the LOCKING-WAITING-issue in the archive, should be more than 100 postings by now?! Have fun (in short: dev is working on a smart version to come by this issue) Burkhard - Original Message - From: "Ernest Chen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 13, 2001 9:36 PM Subject: [JBoss-user] LOCKING-WAITING (CTX) > Hi, > > When I perform jUnit testing with 200 threads on my BMP, there is numerous > LOCKING-WAITING, what do I need to change in order to avoid all these > locking issues? All I'm doing is to retrieve the EJB by primary key and > retrieve it's fields, there is no write. > > Thanks! > > Ernest > > [SecurityUserBean] LOCKING-WAITING (CTX) for id > com.starmedia.helix.security.UserPK@88 ctx.hash 6083741 > [SecurityUserBean] LOCKING-WAITING (CTX) for id > com.starmedia.helix.security.UserPK@88 ctx.hash 6083741 > [SecurityUserBean] LOCKING-WAITING (CTX) for id > com.starmedia.helix.security.UserPK@88 ctx.hash 6083741 > [SecurityUserBean] LOCKING-WAITING (CTX) for id > com.starmedia.helix.security.UserPK@88 ctx.hash 6083741 > [SecurityUserBean] LOCKING-WAITING (CTX) for id > com.starmedia.helix.security.UserPK@88 ctx.hash 6083741 > [SecurityUserBean] LOCKING-WAITING (CTX) for id > com.starmedia.helix.security.UserPK@88 ctx.hash 6083741 > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
The transactions for the relevant functions of this entity bean are defined
as Required in my ejb-jar.xml. (This
worked as expected in Orion, I'm pretty sure that my code is correct.)
Mike
- Original Message -
From: "Victor Langelo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 28, 2001 12:57 PM
Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
> I cannot tell from your description whether the entity bean method's
transaction
> attribute is tx_supports. If it is, then JBoss should be throwing an
exception
> since setRollbackOnly isn't valid in this context.
>
> --Victor
>
> Michael Jara wrote:
>
> > FYI: I took a clue from bug #420714 an tried moving my "setRollbackOnly"
to
> > a session bean. I was doing something like this before in my entity
bean:
> >
> > this.entityContext.setRollbackOnly();
> > throw new StorageSynchronizationException(); // my application exception
> >
> > I changed the entity bean:
> >
> > // this.entityContext.setRollbackOnly();
> > throw new StorageSynchronizationException(); // my application exception
> >
> > And I added to the the stateful session bean which was calling the
entity
> > bean:
> >
> > ...
> > catch(StorageSynchronizationException ex)
> > {
> > this.sessionContext.setRollbackOnly();
> > throw ex;
> > }
> >
> > This works correctly! The problem appears to be specific to entity
beans.
> > Nevertheless, it is still a problem, but at least I have a better
> > workaround.
> >
> > Mike
> >
>
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
Okay, my assumptions about Oracle were incorrect there. (I shouldn't have Oracle, since I have very little experience with it.) However, Sybase ASE seems to be very strict with this. If I use Sybase's SQL tool to execute a command, where I have a table named "ETSUser": select * from ETSUser No problem, I get my result set. However, If I do this: select * from etsuser I get an error back from the database. This is the type of thing JAWS is doing in the 2.4 beta... But only for the custom finder SQL that I have specified in jaws.xml. (The CMP generated parts are correct.) Mike - Original Message - From: "Victor Langelo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 28, 2001 12:31 PM Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly() > Michael Jara wrote: > > > Yes, Sybase ASE is case sensitive as to table and column names. (SQL > > keywords may be any case.) I beleive this is not unique to Sybase, but is > > also the case in some other database servers such as Oracle. JAWS in JBoss > > 2.2.2 works properly, but Beta 2.4 does not... I get SQL errors, and the > > trace shows all of the finder text from my jaws.xml file to be lower-cased. > > > > In Oracle, object names (table, columns, packages, functions, etc) are only case > sensitive if you enclose them in double quotes in your SQL. Otherwise they are > converted to upper case. > > --Victor > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
stServerRef.dispatch(Unknown Source) [RMI TCP Connection(71)-161.218.184.169] ERROR root - at sun.rmi.transport.Transport$1.run(Unknown Source) [RMI TCP Connection(71)-161.218.184.169] ERROR root - at java.security.AccessController.doPrivileged(Native Method) [RMI TCP Connection(71)-161.218.184.169] ERROR root - at sun.rmi.transport.Transport.serviceCall(Unknown Source) [RMI TCP Connection(71)-161.218.184.169] ERROR root - at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) [RMI TCP Connection(71)-161.218.184.169] ERROR root - at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) [RMI TCP Connection(71)-161.218.184.169] ERROR root - at java.lang.Thread.run(Unknown Source) This does not cause any problems in my case. I understand that the LOCKING-WAITING message is normal, after reading through the mailing list archives. However, in a situation such as this where the transaction is not released, it slows the server to a crawl while thousands of LOCKING-WAITING messages go into the logfile (which grows and grows, not unexpected behavior so I'm not complaining.) The transaction eventually times out, but the entity bean remains locked until I restart the application server. Mike - Original Message ----- From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 28, 2001 11:46 AM Subject: RE: [JBoss-user] LOCKING-WAITING after setRollbackOnly() > h > > can't get get from the transaction what the status of the rollback only flag > is? > > quick question do new resources enroll in it none the less? > > the LW is normal but what would you expect (you want and /or spec) > > marcf > > |-----Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Michael Jara > |Sent: Thursday, June 28, 2001 1:05 PM > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly() > | > | > |Yes, Sybase ASE is case sensitive as to table and column names. (SQL > |keywords may be any case.) I beleive this is not unique to Sybase, but is > |also the case in some other database servers such as Oracle. JAWS in JBoss > |2.2.2 works properly, but Beta 2.4 does not... I get SQL errors, and the > |trace shows all of the finder text from my jaws.xml file to be lower-cased. > | > |As to the "setRollbackOnly" problem, I'm guessing that the only way around > |is simply to avoid using "setRollbackOnly". This may present a maintenance > |problem, but with some careful coding, it will be the quickest solution to > |my problem. (I have recently ported our app from Orion to JBoss because > |Orion had problems with EJB security... I guess no app server is perfect.) > | > |Has nobody else noticed this problem? > | > |Mike > | > |- Original Message - > |From: "danch" <[EMAIL PROTECTED]> > |To: <[EMAIL PROTECTED]> > |Sent: Wednesday, June 27, 2001 11:02 PM > |Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly() > | > | > |> Michael Jara wrote: > |> > |> > I've run into a problem previously mentioned in the archives here: > |> > > |http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg03141.html > |> > > |> > > |> > > |> > Does anyone have a good workaround for this (aside from "don't use > |> > setRollbackOnly", or "hack TxCapsule and build it yourself"?) This > |> > seems like a pretty major issue, I'm a little surprsed to see > |it present > |> > in JBoss at this stage (release version 2.2.2.) > |> > > |> > > |> > > |> > After a quick scan of the latest source changes, it didn't > |look to me as > |> > if this had been touched (although I am admittedly clueless as to how > |> > most of this stuff is implemented.) There is a bug logged, #420714, > |> > which seems to refer to this problem. Unfortunately, the > |description is > |> > pretty sparse, so I'm not sure if it is the exact same problem. At any > |> > rate, the bug is unassigned and is marked medium priority. Do any of > |> > you JBoss gurus out there have this on your bug-fix to-do list? (I'd > |> > take a crack at it, but being new to JBoss, I'm not really qualified.) > |> > > |> > > |> > > |> > BTW, I tried deploying my jar in the beta 2.4, and my app wouldn't even > |> > run. It appears that JAWS is broken, it lower-cased all of > |the SQL text > |> > in my custom finders. While this might work for databases such as > |> > Hypersonic, Sybase ASE (what I'm using) is case-s
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
I cannot tell from your description whether the entity bean method's transaction
attribute is tx_supports. If it is, then JBoss should be throwing an exception
since setRollbackOnly isn't valid in this context.
--Victor
Michael Jara wrote:
> FYI: I took a clue from bug #420714 an tried moving my "setRollbackOnly" to
> a session bean. I was doing something like this before in my entity bean:
>
> this.entityContext.setRollbackOnly();
> throw new StorageSynchronizationException(); // my application exception
>
> I changed the entity bean:
>
> // this.entityContext.setRollbackOnly();
> throw new StorageSynchronizationException(); // my application exception
>
> And I added to the the stateful session bean which was calling the entity
> bean:
>
> ...
> catch(StorageSynchronizationException ex)
> {
> this.sessionContext.setRollbackOnly();
> throw ex;
> }
>
> This works correctly! The problem appears to be specific to entity beans.
> Nevertheless, it is still a problem, but at least I have a better
> workaround.
>
> Mike
>
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
Michael Jara wrote: > Yes, Sybase ASE is case sensitive as to table and column names. (SQL > keywords may be any case.) I beleive this is not unique to Sybase, but is > also the case in some other database servers such as Oracle. JAWS in JBoss > 2.2.2 works properly, but Beta 2.4 does not... I get SQL errors, and the > trace shows all of the finder text from my jaws.xml file to be lower-cased. > In Oracle, object names (table, columns, packages, functions, etc) are only case sensitive if you enclose them in double quotes in your SQL. Otherwise they are converted to upper case. --Victor ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
FYI: I took a clue from bug #420714 an tried moving my "setRollbackOnly" to
a session bean. I was doing something like this before in my entity bean:
this.entityContext.setRollbackOnly();
throw new StorageSynchronizationException(); // my application exception
I changed the entity bean:
// this.entityContext.setRollbackOnly();
throw new StorageSynchronizationException(); // my application exception
And I added to the the stateful session bean which was calling the entity
bean:
...
catch(StorageSynchronizationException ex)
{
this.sessionContext.setRollbackOnly();
throw ex;
}
This works correctly! The problem appears to be specific to entity beans.
Nevertheless, it is still a problem, but at least I have a better
workaround.
Mike
- Original Message -
From: "Jara, Michael" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 28, 2001 11:05 AM
Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
> Yes, Sybase ASE is case sensitive as to table and column names. (SQL
> keywords may be any case.) I beleive this is not unique to Sybase, but is
> also the case in some other database servers such as Oracle. JAWS in
JBoss
> 2.2.2 works properly, but Beta 2.4 does not... I get SQL errors, and the
> trace shows all of the finder text from my jaws.xml file to be
lower-cased.
>
> As to the "setRollbackOnly" problem, I'm guessing that the only way around
> is simply to avoid using "setRollbackOnly". This may present a
maintenance
> problem, but with some careful coding, it will be the quickest solution to
> my problem. (I have recently ported our app from Orion to JBoss because
> Orion had problems with EJB security... I guess no app server is
perfect.)
>
> Has nobody else noticed this problem?
>
> Mike
>
> - Original Message -
> From: "danch" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, June 27, 2001 11:02 PM
> Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
>
>
> > Michael Jara wrote:
> >
> > > I've run into a problem previously mentioned in the archives here:
> > >
> http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg03141.html
> > >
> > >
> > >
> > > Does anyone have a good workaround for this (aside from "don't use
> > > setRollbackOnly", or "hack TxCapsule and build it yourself"?) This
> > > seems like a pretty major issue, I'm a little surprsed to see it
present
> > > in JBoss at this stage (release version 2.2.2.)
> > >
> > >
> > >
> > > After a quick scan of the latest source changes, it didn't look to me
as
> > > if this had been touched (although I am admittedly clueless as to how
> > > most of this stuff is implemented.) There is a bug logged, #420714,
> > > which seems to refer to this problem. Unfortunately, the description
is
> > > pretty sparse, so I'm not sure if it is the exact same problem. At
any
> > > rate, the bug is unassigned and is marked medium priority. Do any of
> > > you JBoss gurus out there have this on your bug-fix to-do list? (I'd
> > > take a crack at it, but being new to JBoss, I'm not really qualified.)
> > >
> > >
> > >
> > > BTW, I tried deploying my jar in the beta 2.4, and my app wouldn't
even
> > > run. It appears that JAWS is broken, it lower-cased all of the SQL
text
> > > in my custom finders. While this might work for databases such as
> > > Hypersonic, Sybase ASE (what I'm using) is case-sensitive.
> >
> > Case sensitive with regard to table and column names?
> >
> >
> > -danch
> >
> >
> > ___
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
h can't get get from the transaction what the status of the rollback only flag is? quick question do new resources enroll in it none the less? the LW is normal but what would you expect (you want and /or spec) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Michael Jara |Sent: Thursday, June 28, 2001 1:05 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly() | | |Yes, Sybase ASE is case sensitive as to table and column names. (SQL |keywords may be any case.) I beleive this is not unique to Sybase, but is |also the case in some other database servers such as Oracle. JAWS in JBoss |2.2.2 works properly, but Beta 2.4 does not... I get SQL errors, and the |trace shows all of the finder text from my jaws.xml file to be lower-cased. | |As to the "setRollbackOnly" problem, I'm guessing that the only way around |is simply to avoid using "setRollbackOnly". This may present a maintenance |problem, but with some careful coding, it will be the quickest solution to |my problem. (I have recently ported our app from Orion to JBoss because |Orion had problems with EJB security... I guess no app server is perfect.) | |Has nobody else noticed this problem? | |Mike | |- Original Message - |From: "danch" <[EMAIL PROTECTED]> |To: <[EMAIL PROTECTED]> |Sent: Wednesday, June 27, 2001 11:02 PM |Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly() | | |> Michael Jara wrote: |> |> > I've run into a problem previously mentioned in the archives here: |> > |http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg03141.html |> > |> > |> > |> > Does anyone have a good workaround for this (aside from "don't use |> > setRollbackOnly", or "hack TxCapsule and build it yourself"?) This |> > seems like a pretty major issue, I'm a little surprsed to see |it present |> > in JBoss at this stage (release version 2.2.2.) |> > |> > |> > |> > After a quick scan of the latest source changes, it didn't |look to me as |> > if this had been touched (although I am admittedly clueless as to how |> > most of this stuff is implemented.) There is a bug logged, #420714, |> > which seems to refer to this problem. Unfortunately, the |description is |> > pretty sparse, so I'm not sure if it is the exact same problem. At any |> > rate, the bug is unassigned and is marked medium priority. Do any of |> > you JBoss gurus out there have this on your bug-fix to-do list? (I'd |> > take a crack at it, but being new to JBoss, I'm not really qualified.) |> > |> > |> > |> > BTW, I tried deploying my jar in the beta 2.4, and my app wouldn't even |> > run. It appears that JAWS is broken, it lower-cased all of |the SQL text |> > in my custom finders. While this might work for databases such as |> > Hypersonic, Sybase ASE (what I'm using) is case-sensitive. |> |> Case sensitive with regard to table and column names? |> |> |> -danch |> |> |> ___ |> JBoss-user mailing list |> [EMAIL PROTECTED] |> http://lists.sourceforge.net/lists/listinfo/jboss-user |> | | |___ |JBoss-user mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
Yes, Sybase ASE is case sensitive as to table and column names. (SQL keywords may be any case.) I beleive this is not unique to Sybase, but is also the case in some other database servers such as Oracle. JAWS in JBoss 2.2.2 works properly, but Beta 2.4 does not... I get SQL errors, and the trace shows all of the finder text from my jaws.xml file to be lower-cased. As to the "setRollbackOnly" problem, I'm guessing that the only way around is simply to avoid using "setRollbackOnly". This may present a maintenance problem, but with some careful coding, it will be the quickest solution to my problem. (I have recently ported our app from Orion to JBoss because Orion had problems with EJB security... I guess no app server is perfect.) Has nobody else noticed this problem? Mike - Original Message - From: "danch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 27, 2001 11:02 PM Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly() > Michael Jara wrote: > > > I've run into a problem previously mentioned in the archives here: > > http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg03141.html > > > > > > > > Does anyone have a good workaround for this (aside from "don't use > > setRollbackOnly", or "hack TxCapsule and build it yourself"?) This > > seems like a pretty major issue, I'm a little surprsed to see it present > > in JBoss at this stage (release version 2.2.2.) > > > > > > > > After a quick scan of the latest source changes, it didn't look to me as > > if this had been touched (although I am admittedly clueless as to how > > most of this stuff is implemented.) There is a bug logged, #420714, > > which seems to refer to this problem. Unfortunately, the description is > > pretty sparse, so I'm not sure if it is the exact same problem. At any > > rate, the bug is unassigned and is marked medium priority. Do any of > > you JBoss gurus out there have this on your bug-fix to-do list? (I'd > > take a crack at it, but being new to JBoss, I'm not really qualified.) > > > > > > > > BTW, I tried deploying my jar in the beta 2.4, and my app wouldn't even > > run. It appears that JAWS is broken, it lower-cased all of the SQL text > > in my custom finders. While this might work for databases such as > > Hypersonic, Sybase ASE (what I'm using) is case-sensitive. > > Case sensitive with regard to table and column names? > > > -danch > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
Michael Jara wrote: > I've run into a problem previously mentioned in the archives here: > http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg03141.html > > > > Does anyone have a good workaround for this (aside from "don't use > setRollbackOnly", or "hack TxCapsule and build it yourself"?) This > seems like a pretty major issue, I'm a little surprsed to see it present > in JBoss at this stage (release version 2.2.2.) > > > > After a quick scan of the latest source changes, it didn't look to me as > if this had been touched (although I am admittedly clueless as to how > most of this stuff is implemented.) There is a bug logged, #420714, > which seems to refer to this problem. Unfortunately, the description is > pretty sparse, so I'm not sure if it is the exact same problem. At any > rate, the bug is unassigned and is marked medium priority. Do any of > you JBoss gurus out there have this on your bug-fix to-do list? (I'd > take a crack at it, but being new to JBoss, I'm not really qualified.) > > > > BTW, I tried deploying my jar in the beta 2.4, and my app wouldn't even > run. It appears that JAWS is broken, it lower-cased all of the SQL text > in my custom finders. While this might work for databases such as > Hypersonic, Sybase ASE (what I'm using) is case-sensitive. Case sensitive with regard to table and column names? -danch ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
I've run into a problem previously mentioned in the archives here: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg03141.html Does anyone have a good workaround for this (aside from "don't use setRollbackOnly", or "hack TxCapsule and build it yourself"?) This seems like a pretty major issue, I'm a little surprsed to see it present in JBoss at this stage (release version 2.2.2.) After a quick scan of the latest source changes, it didn't look to me as if this had been touched (although I am admittedly clueless as to how most of this stuff is implemented.) There is a bug logged, #420714, which seems to refer to this problem. Unfortunately, the description is pretty sparse, so I'm not sure if it is the exact same problem. At any rate, the bug is unassigned and is marked medium priority. Do any of you JBoss gurus out there have this on your bug-fix to-do list? (I'd take a crack at it, but being new to JBoss, I'm not really qualified.) BTW, I tried deploying my jar in the beta 2.4, and my app wouldn't even run. It appears that JAWS is broken, it lower-cased all of the SQL text in my custom finders. While this might work for databases such as Hypersonic, Sybase ASE (what I'm using) is case-sensitive. Any thoughts are greatly appreciated. Thanks, Mike
Re: [JBoss-user] LOCKING-WAITING
Hi, ivanhoe Abrahams wrote: > Could anyone point me in the right direction when it comes to solving > the LOCKING-WAITING problem > It hangs my client/keeps the server so busy that everything slows down > to a snail's pace. In the current CVS version of JBoss is a partial fix for that and some developers are just working on the final fix. I didn't try the partial fix yet, if you do, it would be nice to report back to the list (or at least to me) how it changes behaviour. > Ps. a good explanation of the problem (a deadlock I assume) would be > interesting to chew on. Essentially quoting from one of my previous mails: - begin quote - simplest deadlock scenario: timeSession/TX ASession/TX B - T1 access Entity 1 T2 access Entity 2 T3 try access Entity 2, must wait for TX B to finish T4 try access Entity 1, must wait for TX A to finish ^^^ this deadlocks, each session/Tx waiting for the other to complete. > Is there a nice way to handle this, or an easy way to debug it? Or is > this going to be a nightmare to fix? The only thing to do about that with the current EJB spec is to try to access ALL deadlock prone beans in the same order (see the 'dining philosophers problem' in the JAVA tutorial). I.e. you could attempt to access them in increasing Primary Key order from all clients. In the above example the session/TX B then would try to get Entity 1 first before accessing Entity 2, waiting there, and session/TX A could complete. In real world, this ordered access, even with moderately complex applications, seems near to impossible to implement, especially if you allow interactive access to several lock prone resources in one (long lived) transaction, where you can't control the order. In such cases there exists a well defined protocol in the relational world, that has proven to work very well and can be followed by any client. It's based on locking all deadlock prone resources before doing any modification and GIVING UP ALL LOCKS, when one lock can't be obtained, thus allowing other clients to proceed. But the EJB spec is mostly silent about locking, there is no requirement at all to support lock detection (besides timeout with distributed TX), thus you can't follow that with EJB. - end quote - ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] LOCKING-WAITING
Hey, there is no problem. You can reduce the log's size by removing the "Debug" option from the file logger in jboss.conf HTH, Simon > -Original Message- > From: madhu [mailto:[EMAIL PROTECTED]] > Sent: giovedì 3 maggio 2001 16:59 > To: [EMAIL PROTECTED] > Subject: [JBoss-user] LOCKING-WAITING > > > Hi, > I am facing a problem with an Entity Bean. My > Application is getting > hanged. My server.log file is containing the follow entries in it. > > > [SecurityConfigSettingsBean] LOCKING-WAITING (TRANSACTION) > for id 1 ctx.hash > 7929530 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=MADHU//37, > BranchQual=] > [SecurityConfigSettingsBean] LOCKING-WAITING (TRANSACTION) > for id 1 ctx.hash > 7929530 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=MADHU//37, > BranchQual=] > [SecurityConfigSettingsBean] LOCKING-WAITING (TRANSACTION) > for id 1 ctx.hash > 7929530 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=MADHU//37, > BranchQual=] > [SecurityConfigSettingsBean] LOCKING-WAITING (TRANSACTION) > for id 1 ctx.hash > 7929530 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=MADHU//37, > BranchQual=] > [SecurityConfigSettingsBean] LOCKING-WAITING (TRANSACTION) > for id 1 ctx.hash > 7929530 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=MADHU//37, > BranchQual=] > [SecurityConfigSettingsBean] LOCKING-WAITING (TRANSACTION) > for id 1 ctx.hash > 7929530 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=MADHU//37, > BranchQual=] > [SecurityConfigSettingsBean] LOCKING-WAITING (TRANSACTION) > for id 1 ctx.hash > 7929530 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=MADHU//37, > BranchQual=] > [JMX RMI Connector] Stopping > [JMX RMI Connector] Stopped > [JMX RMI Adaptor] Stopping > [JMX RMI Adaptor] Stopped > [BlackBoxDS] Stopping > [BlackBoxDS] Stopped > > [SecurityConfigSettingsBean] LOCKING-WAITING (TRANSACTION) > for id 1 ctx.hash > 7929530 tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=MADHU//37, > BranchQual=] > > The above line is getting printed into the Server.log file > for some lakhs of > times, my server.log file is reaching a size of 45 MB and I > its becoming > impossible to open the server.log file. Anyhow I managed to open the > server.log file and could find this entry throughout the file. > > Can Anybody please help me findout what the problem is?. > > I am using JBoss 2.1, Linux 7.0, JDK 1.3.1, Oracle 8 > > Your help will be appreciated. > > Regards, > Madhu > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
I've investigated a little bit into the sourcecode (CVS as of April, 29th)
and found the following in TxCapsule.registerSynchronization():
// OSH: EntitySynchronizationInterceptor bug is fixed long ago,
// and since nobody seems to get the warning anymore it should
// be safe to be JTA-conformant.
// In case of trouble, try changing "true" below to "false".
if (true)
throw new RollbackException("Already marked for rollback");
else {
// Workaround for EntitySynchronizationInterceptor bug.
Logger.warning("TxCapsule: Violating JTA by adding
synchronization to a transaction marked for rollback.");
break;
}
I did change "true" to "false" and voila, no LOCKING-WAITING anymore. Of
course I got the expected warning on the console, followed by this stack
trace:
[Specification] TxCapsule: Violating JTA by adding synchronization to a
transaction marked for rollback.
[Specification] javax.ejb.EJBException
[Specification] at
org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity(CMPPersistenceManage
r.java:396)
[Specification] at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor$InstanceSynchronizati
on.beforeCompletion(EntitySynchronizationInterceptor.java:342)
[Specification] at
org.jboss.tm.TxCapsule.doBeforeCompletion(TxCapsule.java:1228)
[Specification] at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:410)
[Specification] at
org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:88)
[Specification] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:307)
[Specification] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[Specification] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:19
0)
[Specification] at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[Specification] at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:323)
[Specification] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI
nvoker.java:392)
[Specification] at java.lang.reflect.Method.invoke(Native Method)
[Specification] at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
[Specification] at sun.rmi.transport.Transport$1.run(Transport.java:152)
[Specification] at java.security.AccessController.doPrivileged(Native
Method)
[Specification] at
sun.rmi.transport.Transport.serviceCall(Transport.java:148)
[Specification] at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465)
[Specification] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:7
06)
[Specification] at java.lang.Thread.run(Thread.java:484)
Obviously, the bug in EntitySynchronizationInterceptor is still there :-(
Will anybody fix this for release 2.2.2? We're going to use JBoss in a
productive environment, so I'd like to use the stable 2.2 branch instead of
the 2.3 developer version.
Achim
- Original Message -
From: "danch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 27, 2001 8:33 PM
Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
> I'll put together a little sample and look into this. By my reading of
> the spec, you should be able to call into the bean (even the same
> instance) after you call setRollbackOnly and throw an application
> exception. Even if that weren't legal, locking-waiting would not be what
> we'd want to see.
>
> -danch
>
> Achim Demelt wrote:
> >
> > > What version of JBoss is this?
> > >
> >
> > 2.2 binary distribution w/ tomcat 3.2.1
> >
> > > The Classification that's being passed in is null, correct? Otherwise
> > > commenting out the call to setRollbackOnly should have no effect.
> > >
> >
> > Yes, it's null. Oops, I see I've copied the wrong method into the email,
but
> > anyway, all three methods (setClassification, setStatus, setType) have a
> > similar implementation, and are all called with null arguments. So
> > setRollbackOnly is definitely called.
> >
> > > The test client calls the entity directly (not through a session
> > > wrapper), correct?
> > >
> >
> > Correct.
> >
> > Achim
> >
> > > -danch
> > >
> > > Achim Demelt wrote:
> > > >
> > > > hi,
> > > >
> > > > I have a CMP entity bean and a simple test client. one of the bean
> > methods
> > > > is
> > > >
> > > > public void setClassification(Classification param) throws
> > > > LocalizedAppEventException {
> > > > if (param == null) {
> > > > ctx.setRollbackOnly();
> > > >
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
I'll put together a little sample and look into this. By my reading of
the spec, you should be able to call into the bean (even the same
instance) after you call setRollbackOnly and throw an application
exception. Even if that weren't legal, locking-waiting would not be what
we'd want to see.
-danch
Achim Demelt wrote:
>
> > What version of JBoss is this?
> >
>
> 2.2 binary distribution w/ tomcat 3.2.1
>
> > The Classification that's being passed in is null, correct? Otherwise
> > commenting out the call to setRollbackOnly should have no effect.
> >
>
> Yes, it's null. Oops, I see I've copied the wrong method into the email, but
> anyway, all three methods (setClassification, setStatus, setType) have a
> similar implementation, and are all called with null arguments. So
> setRollbackOnly is definitely called.
>
> > The test client calls the entity directly (not through a session
> > wrapper), correct?
> >
>
> Correct.
>
> Achim
>
> > -danch
> >
> > Achim Demelt wrote:
> > >
> > > hi,
> > >
> > > I have a CMP entity bean and a simple test client. one of the bean
> methods
> > > is
> > >
> > > public void setClassification(Classification param) throws
> > > LocalizedAppEventException {
> > > if (param == null) {
> > > ctx.setRollbackOnly();
> > > throw new
> > > LocalizedAppEventException("isis.masterdata.invalidClassification");
> > > }
> > > this.classification = param.intValue();
> > > }
> > >
> > > the client calls this method and another one, which is more or less
> > > identical to the one above:
> > >
> > > try {
> > > spec.setStatus(null);
> > > }
> > > catch (LocalizedAppEventException e) {
> > > // that's ok, ignore
> > > }
> > >
> > > try {
> > > spec.setType(null);
> > > }
> > > catch (LocalizedAppEventException e) {
> > > // that's ok, ignore
> > > }
> > >
> > > the first invocation is OK, the exception is thrown. on the second
> > > invocation, though, the client hangs. the server produces this line in
> the
> > > log file:
> > >
> > > [Specification] LOCKING-WAITING (TRANSACTION) for id
> > > com.tiscon.isis.masterdata.ejb.SpecificationPK@1e ctx.hash 2721646
> > > tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=c197//81,
> BranchQual=]
> > >
> > > As far as I've understood earlier postings in the list, this message
> usually
> > > occurs in case of a deadlock with non-reentrant beans. OK, my bean *is*
> > > non-reentrant, but there is only one client thread, and, obviously, no
> > > callbacks. If I uncomment the call to setRollbackOnly() everything works
> > > fine. What's the problem here?
> > >
> > > Thanks,
> > > Achim
> > >
> > > ___
> > > JBoss-user mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > Confidential e-mail for addressee only. Access to this e-mail by anyone
> else is unauthorized.
> > If you have received this message in error, please notify the sender
> immediately by reply e-mail
> > and destroy the original communication.
> >
> >
> > ___
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
> What version of JBoss is this?
>
2.2 binary distribution w/ tomcat 3.2.1
> The Classification that's being passed in is null, correct? Otherwise
> commenting out the call to setRollbackOnly should have no effect.
>
Yes, it's null. Oops, I see I've copied the wrong method into the email, but
anyway, all three methods (setClassification, setStatus, setType) have a
similar implementation, and are all called with null arguments. So
setRollbackOnly is definitely called.
> The test client calls the entity directly (not through a session
> wrapper), correct?
>
Correct.
Achim
> -danch
>
> Achim Demelt wrote:
> >
> > hi,
> >
> > I have a CMP entity bean and a simple test client. one of the bean
methods
> > is
> >
> > public void setClassification(Classification param) throws
> > LocalizedAppEventException {
> > if (param == null) {
> > ctx.setRollbackOnly();
> > throw new
> > LocalizedAppEventException("isis.masterdata.invalidClassification");
> > }
> > this.classification = param.intValue();
> > }
> >
> > the client calls this method and another one, which is more or less
> > identical to the one above:
> >
> > try {
> > spec.setStatus(null);
> > }
> > catch (LocalizedAppEventException e) {
> > // that's ok, ignore
> > }
> >
> > try {
> > spec.setType(null);
> > }
> > catch (LocalizedAppEventException e) {
> > // that's ok, ignore
> > }
> >
> > the first invocation is OK, the exception is thrown. on the second
> > invocation, though, the client hangs. the server produces this line in
the
> > log file:
> >
> > [Specification] LOCKING-WAITING (TRANSACTION) for id
> > com.tiscon.isis.masterdata.ejb.SpecificationPK@1e ctx.hash 2721646
> > tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=c197//81,
BranchQual=]
> >
> > As far as I've understood earlier postings in the list, this message
usually
> > occurs in case of a deadlock with non-reentrant beans. OK, my bean *is*
> > non-reentrant, but there is only one client thread, and, obviously, no
> > callbacks. If I uncomment the call to setRollbackOnly() everything works
> > fine. What's the problem here?
> >
> > Thanks,
> > Achim
> >
> > ___
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> Confidential e-mail for addressee only. Access to this e-mail by anyone
else is unauthorized.
> If you have received this message in error, please notify the sender
immediately by reply e-mail
> and destroy the original communication.
>
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
What version of JBoss is this?
The Classification that's being passed in is null, correct? Otherwise
commenting out the call to setRollbackOnly should have no effect.
The test client calls the entity directly (not through a session
wrapper), correct?
-danch
Achim Demelt wrote:
>
> hi,
>
> I have a CMP entity bean and a simple test client. one of the bean methods
> is
>
> public void setClassification(Classification param) throws
> LocalizedAppEventException {
> if (param == null) {
> ctx.setRollbackOnly();
> throw new
> LocalizedAppEventException("isis.masterdata.invalidClassification");
> }
> this.classification = param.intValue();
> }
>
> the client calls this method and another one, which is more or less
> identical to the one above:
>
> try {
> spec.setStatus(null);
> }
> catch (LocalizedAppEventException e) {
> // that's ok, ignore
> }
>
> try {
> spec.setType(null);
> }
> catch (LocalizedAppEventException e) {
> // that's ok, ignore
> }
>
> the first invocation is OK, the exception is thrown. on the second
> invocation, though, the client hangs. the server produces this line in the
> log file:
>
> [Specification] LOCKING-WAITING (TRANSACTION) for id
> com.tiscon.isis.masterdata.ejb.SpecificationPK@1e ctx.hash 2721646
> tx:TransactionImpl:XidImpl [FormatId=257, GlobalId=c197//81, BranchQual=]
>
> As far as I've understood earlier postings in the list, this message usually
> occurs in case of a deadlock with non-reentrant beans. OK, my bean *is*
> non-reentrant, but there is only one client thread, and, obviously, no
> callbacks. If I uncomment the call to setRollbackOnly() everything works
> fine. What's the problem here?
>
> Thanks,
> Achim
>
> ___
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
Confidential e-mail for addressee only. Access to this e-mail by anyone else is
unauthorized.
If you have received this message in error, please notify the sender immediately by
reply e-mail
and destroy the original communication.
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] LOCKING-WAITING
Hi, At 13:43 21.3.2001 -, you wrote: >I'm also working on that, I fixed it but didn't tested it enough. >Keep me informed if you will work on this. I was only planning to drop the patch in...didn't want it to get lost. But you can have this one, you're more familiar with it :) Enjoy! -- Juha ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] LOCKING-WAITING
Hey, At 13:43 21.3.2001 -, you wrote: >I'm also working on that, I fixed it but didn't tested it enough. >Keep me informed if you will work on this. I was only planning to drop the patch in...didn't want it to get lost. But you can have this one, you're more familiar with it :) Enjoy! -- Juha ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING
Hi,
On Wed, 21 Mar 2001, Alexander Kogan wrote:
> marc fleury wrote:
> >
> > Just out of curiousity Simone...
> >
> > when we benched at SUN one of the big difference under load was the thread
> > management.
> >
> > The best in terms of resource usage was put the thread to sleep (with a 5
> > sec timeout) and notify (1) and that REALLY flew and scaled REALLY well
> > because the usage of CPU and sync was really low.
>
> This would be very good idea. For now, especially on Tru64 with JDK 1.3-1
> LOKING-WAITING stuff eats a lot CPU and much more slow than on Sun.
>
> And why do we need timeout there? Is it possible to implement a sort
> of queue for that? Than you can put a new thread to the waiting list and
> when the current thread is done with the transaction it can call
> notify to release the tread from the waiting list.
> Am I talking junk?
i've developed fair queue (it maintains the order of requests) for
obtaining exclusive lock (token). Maybe it could help ...
Dragan
// Distributable under GPL License
// Author Dragan Milic ([EMAIL PROTECTED])
import java.lang.*;
import java.util.*;
public class FairThreadQueue {
LinkedList threadQueue=new LinkedList();
HashSet threadSet=new HashSet();
public FairThreadQueue() {
}
public void getToken() {
Lock lock=null;
Thread currentThread=Thread.currentThread();
synchronized (this) {
// sanity check, for reenterant beans
if (threadSet.contains(currentThread))
return;
threadSet.add(currentThread);
lock=new Lock();
threadQueue.add(lock);
// if there are no other threads in queue this one can have a token
if (threadQueue.size() == 1)
return;
}
// ok, there is some thread running ... just wait in queue
lock.waitForUnlock();
}
public synchronized void returnToken() {
Thread currentThread=Thread.currentThread();
// another sanity check
if (!threadSet.contains(currentThread))
return;
// if current thread is active it must be first in queue
threadQueue.removeFirst();
threadSet.remove(currentThread);
if (threadQueue.size() >0) {
Lock first=(Lock)threadQueue.getFirst();
first.unlock();
}
}
// because of possible lost wait there is necesarry to check
// if lock has been unlocked
public static class Lock {
boolean unlocked=false;
public void Lock() {
}
public synchronized void waitForUnlock() {
if (unlocked)
return;
else {
try {
wait();
} catch (InterruptedException ie) {
}
}
}
public synchronized void unlock() {
unlocked=true;
notify();
}
}
// below is only a test for functionality and fairness
public static void main(String argv[]) {
FairThreadQueue queue=new FairThreadQueue();
for (int i=0; i<200; i++) {
QueueTest qt=new QueueTest(queue, i);
qt.start();
}
}
public static class QueueTest extends Thread {
static int count=0;
FairThreadQueue ftq;
int threadNr;
QueueTest(FairThreadQueue ftq, int threadNr) {
this.ftq=ftq;
this.threadNr=threadNr;
}
public void run() {
ftq.getToken();
// test for reenterant test :)
ftq.getToken();
System.out.println("current counter "+count+" thread "+threadNr);
count++;
ftq.returnToken();
}
}
}
Re: [JBoss-user] LOCKING-WAITING
"Swarr, Bob" wrote: > > To address these problems a number of theorticians in concurrent > programming, such as Brinch Hansen, developed the idea of a monitor. I guess > today we would call it a design pattern. Some writers claim that Java > wait() and notify() implement a monitor, although I've read that Brinch > Hansen is critical of the Java implementation. There was a quite good article about the java thread monitor in developerlife.com by Nazmul Idris http://65.1.136.127/developerlife/lessons/advancedthreads/default.htm -- __ Alexander Kogan PTC www.ptc.com [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] LOCKING-WAITING
Hey, > Which leads to a question since I'm a JBoss novice. Is there > a way to set > the number of threads in JBoss? I use WebLogic regularly and > it provides a > configuration parameter that allows you to set the number of > threads in the > VM that the server uses. No. (but this is open source so I should say "not yet" :) Simon ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] LOCKING-WAITING
Marc, I think that the body of opinion in CS literature is consistent with your findings. Busy/wait burns cpu and leads to various programming problems (race, starvation, deadlock, etc). To address these problems a number of theorticians in concurrent programming, such as Brinch Hansen, developed the idea of a monitor. I guess today we would call it a design pattern. Some writers claim that Java wait() and notify() implement a monitor, although I've read that Brinch Hansen is critical of the Java implementation. Also, in the EJB benchmarks that I've run I've always found that if you try to run too many threads, you will reach a point where application performance declines, sometimes really dramatically. So, you need use the Goldilocks principle in tuning your application - not too few threads and not too many. Which leads to a question since I'm a JBoss novice. Is there a way to set the number of threads in JBoss? I use WebLogic regularly and it provides a configuration parameter that allows you to set the number of threads in the VM that the server uses. Bob -Original Message- From: Alexander Kogan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 10:07 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] LOCKING-WAITING marc fleury wrote: > > Just out of curiousity Simone... > > when we benched at SUN one of the big difference under load was the thread > management. > > The best in terms of resource usage was put the thread to sleep (with a 5 > sec timeout) and notify (1) and that REALLY flew and scaled REALLY well > because the usage of CPU and sync was really low. This would be very good idea. For now, especially on Tru64 with JDK 1.3-1 LOKING-WAITING stuff eats a lot CPU and much more slow than on Sun. And why do we need timeout there? Is it possible to implement a sort of queue for that? Than you can put a new thread to the waiting list and when the current thread is done with the transaction it can call notify to release the tread from the waiting list. Am I talking junk? > > Do you put the threads to sleep in the current code base? I couldn't go down > and look for myself, plus a little introduction on what you did with the new > structure of cache sync would be helpful. As far as I can see from the code - no. Again, sorry if I am mistaken. > > regards > > torquemada -- __ Alexander Kogan PTC www.ptc.com [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] LOCKING-WAITING
marc fleury wrote: > > Just out of curiousity Simone... > > when we benched at SUN one of the big difference under load was the thread > management. > > The best in terms of resource usage was put the thread to sleep (with a 5 > sec timeout) and notify (1) and that REALLY flew and scaled REALLY well > because the usage of CPU and sync was really low. This would be very good idea. For now, especially on Tru64 with JDK 1.3-1 LOKING-WAITING stuff eats a lot CPU and much more slow than on Sun. And why do we need timeout there? Is it possible to implement a sort of queue for that? Than you can put a new thread to the waiting list and when the current thread is done with the transaction it can call notify to release the tread from the waiting list. Am I talking junk? > > Do you put the threads to sleep in the current code base? I couldn't go down > and look for myself, plus a little introduction on what you did with the new > structure of cache sync would be helpful. As far as I can see from the code - no. Again, sorry if I am mistaken. > > regards > > torquemada -- __ Alexander Kogan PTC www.ptc.com [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494 ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] LOCKING-WAITING
Marc, > Just out of curiousity Simone... > > when we benched at SUN one of the big difference under load > was the thread > management. > > The best in terms of resource usage was put the thread to > sleep (with a 5 > sec timeout) and notify (1) and that REALLY flew and scaled > REALLY well > because the usage of CPU and sync was really low. Yes. > Do you put the threads to sleep in the current code base? No. This issue was raised by Ole, and I fixed it, as I told, but not committed (not tested enough; also the 2.0 one was buggy; I also (like Ole for his DTM - if I'm right) get some rare exception under heavy load tests, and need to track it down). BTW the scheme is the same as before: wait and notify (not notifyAll), in the same places, plus many fixes. > I > couldn't go down > and look for myself, plus a little introduction on what you > did with the new > structure of cache sync would be helpful. OK, I'll try to find the time for that also. You'd like something for JBG docs (for sell) ? > regards > > torquemada Ugh ? Torquemada ? Would you like to burn me at the stake like he did ? Beware then, I will fortify my email server, and you won't ever pass. Ah ! LOL! Simon ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] LOCKING-WAITING
Just out of curiousity Simone...
when we benched at SUN one of the big difference under load was the thread
management.
The best in terms of resource usage was put the thread to sleep (with a 5
sec timeout) and notify (1) and that REALLY flew and scaled REALLY well
because the usage of CPU and sync was really low.
Do you put the threads to sleep in the current code base? I couldn't go down
and look for myself, plus a little introduction on what you did with the new
structure of cache sync would be helpful.
regards
torquemada
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Bordet,
|Simone
|Sent: Wednesday, March 21, 2001 8:44 AM
|To: '[EMAIL PROTECTED]'
|Subject: RE: [JBoss-user] LOCKING-WAITING
|
|
|Juha,
|
|> Hi,
|>
|> will do (once the cvs is back online again)
|
|I'm also working on that, I fixed it but didn't tested it enough.
|Keep me informed if you will work on this.
|
|Thanks
|
|Simon
|
|>
|> -- Juha
|>
|>
|> At 00:26 21.3.2001 +0100, you wrote:
|> >I have the problem too. (having a log file of 400mb)
|> >
|> >will this fix be checked into cvs?
|> >
|> >thx markus
|> >
|> >
|> >-Original Message-
|> >From: Bill Burke [mailto:[EMAIL PROTECTED]]
|> >Sent: Dienstag, 20. März 2001 21:14
|> >To: [EMAIL PROTECTED]
|> >Subject: Re: [JBoss-user] LOCKING-WAITING
|> >
|> >
|> >You're may be getting such a performance hit because of all the
|> >LOCKING-WAITING messages being sent to
|> jboss/logs/server.log. Check out
|> >
|> >that file, my guess it will be very, very large.
|> >
|> >BTW, please don't remove that message. It is very useful
|> for debugging
|> >purposes.
|> >
|> >Here's a fix for that very problem,
|> >
|> >in org.jboss.ejb.plugins.EntityInstanceInterceptor I changed
|> the invoke
|> >method.
|> >
|> > public Object invoke(MethodInvocation mi)
|> > throws Exception
|> > {
|> > // The id store is a CacheKey in the case of Entity
|> > CacheKey key = (CacheKey)mi.getId();
|> >
|> > // Get cache
|> > AbstractInstanceCache cache =
|> >(AbstractInstanceCache)container.getInstanceCache();
|> > Sync mutex = (Sync)cache.getLock(key);
|> >
|> > EnterpriseContext ctx = null;
|> >
|> > try
|> > {
|> > boolean waitingOnTransaction = false; // So we
|> don't output
|> >LOCKING-WAITING all the time
|> > boolean waitingOnContext = false; // So we don't output
|> >LOCKING-WAITING all the time
|> >
|> > do
|> > {
|> > if (mi.getTransaction() != null &&
|> >mi.getTransaction().getStatus() == Status.STATUS_MARKED_ROLLBACK)
|> > throw new RuntimeException("Transaction marked for
|> >rollback, possibly a timeout");
|> >
|> > try
|> > {
|> >
|> > mutex.acquire();
|> >
|> > // Get context
|> > ctx = cache.get(key);
|> >
|> > // Do we have a running transaction with
|> the context
|> > Transaction tx = ctx.getTransaction();
|> > if (tx != null &&
|> > // And are we trying to enter with another
|> >transaction
|> > !tx.equals(mi.getTransaction()))
|> > {
|> > // Let's put the thread to sleep a
|> lock release
|> >will wake the thread
|> > // Possible deadlock
|> > if (!waitingOnTransaction)
|> > {
|> > Logger.debug("LOCKING-WAITING
|> (TRANSACTION)
|> >for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+" tx:"+((tx
|> == null) ?
|> >"null" : tx.toString()));
|> > waitingOnTransaction = true;
|> > }
|> >
|> > // Try your luck again
|> > ctx = null;
|> > continue;
|> > }
|> > else
|> > {
|> > if (waitingOnTransaction)
|> > {
|> > Logger.debug("FINISHED-LOCKING-WAITING
|> >(TRANSACTION) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+"
|> >tx:"+((tx == null) ? "null"
RE: [JBoss-user] LOCKING-WAITING
Juha,
> Hi,
>
> will do (once the cvs is back online again)
I'm also working on that, I fixed it but didn't tested it enough.
Keep me informed if you will work on this.
Thanks
Simon
>
> -- Juha
>
>
> At 00:26 21.3.2001 +0100, you wrote:
> >I have the problem too. (having a log file of 400mb)
> >
> >will this fix be checked into cvs?
> >
> >thx markus
> >
> >
> >-Original Message-
> >From: Bill Burke [mailto:[EMAIL PROTECTED]]
> >Sent: Dienstag, 20. März 2001 21:14
> >To: [EMAIL PROTECTED]
> >Subject: Re: [JBoss-user] LOCKING-WAITING
> >
> >
> >You're may be getting such a performance hit because of all the
> >LOCKING-WAITING messages being sent to
> jboss/logs/server.log. Check out
> >
> >that file, my guess it will be very, very large.
> >
> >BTW, please don't remove that message. It is very useful
> for debugging
> >purposes.
> >
> >Here's a fix for that very problem,
> >
> >in org.jboss.ejb.plugins.EntityInstanceInterceptor I changed
> the invoke
> >method.
> >
> > public Object invoke(MethodInvocation mi)
> > throws Exception
> > {
> > // The id store is a CacheKey in the case of Entity
> > CacheKey key = (CacheKey)mi.getId();
> >
> > // Get cache
> > AbstractInstanceCache cache =
> >(AbstractInstanceCache)container.getInstanceCache();
> > Sync mutex = (Sync)cache.getLock(key);
> >
> > EnterpriseContext ctx = null;
> >
> > try
> > {
> > boolean waitingOnTransaction = false; // So we
> don't output
> >LOCKING-WAITING all the time
> > boolean waitingOnContext = false; // So we don't output
> >LOCKING-WAITING all the time
> >
> > do
> > {
> > if (mi.getTransaction() != null &&
> >mi.getTransaction().getStatus() == Status.STATUS_MARKED_ROLLBACK)
> > throw new RuntimeException("Transaction marked for
> >rollback, possibly a timeout");
> >
> > try
> > {
> >
> > mutex.acquire();
> >
> > // Get context
> > ctx = cache.get(key);
> >
> > // Do we have a running transaction with
> the context
> > Transaction tx = ctx.getTransaction();
> > if (tx != null &&
> > // And are we trying to enter with another
> >transaction
> > !tx.equals(mi.getTransaction()))
> > {
> > // Let's put the thread to sleep a
> lock release
> >will wake the thread
> > // Possible deadlock
> > if (!waitingOnTransaction)
> > {
> > Logger.debug("LOCKING-WAITING
> (TRANSACTION)
> >for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+" tx:"+((tx
> == null) ?
> >"null" : tx.toString()));
> > waitingOnTransaction = true;
> > }
> >
> > // Try your luck again
> > ctx = null;
> > continue;
> > }
> > else
> > {
> > if (waitingOnTransaction)
> > {
> > Logger.debug("FINISHED-LOCKING-WAITING
> >(TRANSACTION) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+"
> >tx:"+((tx == null) ? "null" : tx.toString()));
> > waitingOnTransaction = false;
> > }
> > // If we get here it's the right tx, or no tx
> > if (!ctx.isLocked())
> > {
> > //take it!
> > ctx.lock();
> > }
> > else
> > {
> > if (!isCallAllowed(mi)) {
> >
> > // Go to sleep and wait for
> the lock to be
> >
> >released
> > // This is not one of the
> "home calls" so
> >we need to wait for the lock
> >
> > // Possible deadlo
RE: [JBoss-user] LOCKING-WAITING
Hi,
will do (once the cvs is back online again)
-- Juha
At 00:26 21.3.2001 +0100, you wrote:
>I have the problem too. (having a log file of 400mb)
>
>will this fix be checked into cvs?
>
>thx markus
>
>
>-Original Message-
>From: Bill Burke [mailto:[EMAIL PROTECTED]]
>Sent: Dienstag, 20. März 2001 21:14
>To: [EMAIL PROTECTED]
>Subject: Re: [JBoss-user] LOCKING-WAITING
>
>
>You're may be getting such a performance hit because of all the
>LOCKING-WAITING messages being sent to jboss/logs/server.log. Check out
>
>that file, my guess it will be very, very large.
>
>BTW, please don't remove that message. It is very useful for debugging
>purposes.
>
>Here's a fix for that very problem,
>
>in org.jboss.ejb.plugins.EntityInstanceInterceptor I changed the invoke
>method.
>
> public Object invoke(MethodInvocation mi)
> throws Exception
> {
> // The id store is a CacheKey in the case of Entity
> CacheKey key = (CacheKey)mi.getId();
>
> // Get cache
> AbstractInstanceCache cache =
>(AbstractInstanceCache)container.getInstanceCache();
> Sync mutex = (Sync)cache.getLock(key);
>
> EnterpriseContext ctx = null;
>
> try
> {
> boolean waitingOnTransaction = false; // So we don't output
>LOCKING-WAITING all the time
> boolean waitingOnContext = false; // So we don't output
>LOCKING-WAITING all the time
>
> do
> {
> if (mi.getTransaction() != null &&
>mi.getTransaction().getStatus() == Status.STATUS_MARKED_ROLLBACK)
> throw new RuntimeException("Transaction marked for
>rollback, possibly a timeout");
>
> try
> {
>
> mutex.acquire();
>
> // Get context
> ctx = cache.get(key);
>
> // Do we have a running transaction with the context
> Transaction tx = ctx.getTransaction();
> if (tx != null &&
> // And are we trying to enter with another
>transaction
> !tx.equals(mi.getTransaction()))
> {
> // Let's put the thread to sleep a lock release
>will wake the thread
> // Possible deadlock
> if (!waitingOnTransaction)
> {
> Logger.debug("LOCKING-WAITING (TRANSACTION)
>for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+" tx:"+((tx == null) ?
>"null" : tx.toString()));
> waitingOnTransaction = true;
> }
>
> // Try your luck again
> ctx = null;
> continue;
> }
> else
> {
> if (waitingOnTransaction)
> {
> Logger.debug("FINISHED-LOCKING-WAITING
>(TRANSACTION) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+"
>tx:"+((tx == null) ? "null" : tx.toString()));
> waitingOnTransaction = false;
> }
> // If we get here it's the right tx, or no tx
> if (!ctx.isLocked())
> {
> //take it!
> ctx.lock();
> }
> else
> {
> if (!isCallAllowed(mi)) {
>
> // Go to sleep and wait for the lock to be
>
>released
> // This is not one of the "home calls" so
>we need to wait for the lock
>
> // Possible deadlock
> if (!waitingOnContext) {
> Logger.debug("LOCKING-WAITING (CTX)
>for id "+ctx.getId()+" ctx.hash "+ctx.hashCode());
> waitingOnContext = true;
> }
>
> // Try your luck again
> ctx = null;
> continue;
> // Not allowed reentrant call
> //throw new RemoteException("Reentrant
>call");
> }
> else
> {
> if (waitingOnContext) {
>
RE: [JBoss-user] LOCKING-WAITING
I have the problem too. (having a log file of 400mb)
will this fix be checked into cvs?
thx markus
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Dienstag, 20. März 2001 21:14
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] LOCKING-WAITING
You're may be getting such a performance hit because of all the
LOCKING-WAITING messages being sent to jboss/logs/server.log. Check out
that file, my guess it will be very, very large.
BTW, please don't remove that message. It is very useful for debugging
purposes.
Here's a fix for that very problem,
in org.jboss.ejb.plugins.EntityInstanceInterceptor I changed the invoke
method.
public Object invoke(MethodInvocation mi)
throws Exception
{
// The id store is a CacheKey in the case of Entity
CacheKey key = (CacheKey)mi.getId();
// Get cache
AbstractInstanceCache cache =
(AbstractInstanceCache)container.getInstanceCache();
Sync mutex = (Sync)cache.getLock(key);
EnterpriseContext ctx = null;
try
{
boolean waitingOnTransaction = false; // So we don't output
LOCKING-WAITING all the time
boolean waitingOnContext = false; // So we don't output
LOCKING-WAITING all the time
do
{
if (mi.getTransaction() != null &&
mi.getTransaction().getStatus() == Status.STATUS_MARKED_ROLLBACK)
throw new RuntimeException("Transaction marked for
rollback, possibly a timeout");
try
{
mutex.acquire();
// Get context
ctx = cache.get(key);
// Do we have a running transaction with the context
Transaction tx = ctx.getTransaction();
if (tx != null &&
// And are we trying to enter with another
transaction
!tx.equals(mi.getTransaction()))
{
// Let's put the thread to sleep a lock release
will wake the thread
// Possible deadlock
if (!waitingOnTransaction)
{
Logger.debug("LOCKING-WAITING (TRANSACTION)
for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+" tx:"+((tx == null) ?
"null" : tx.toString()));
waitingOnTransaction = true;
}
// Try your luck again
ctx = null;
continue;
}
else
{
if (waitingOnTransaction)
{
Logger.debug("FINISHED-LOCKING-WAITING
(TRANSACTION) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+"
tx:"+((tx == null) ? "null" : tx.toString()));
waitingOnTransaction = false;
}
// If we get here it's the right tx, or no tx
if (!ctx.isLocked())
{
//take it!
ctx.lock();
}
else
{
if (!isCallAllowed(mi)) {
// Go to sleep and wait for the lock to be
released
// This is not one of the "home calls" so
we need to wait for the lock
// Possible deadlock
if (!waitingOnContext) {
Logger.debug("LOCKING-WAITING (CTX)
for id "+ctx.getId()+" ctx.hash "+ctx.hashCode());
waitingOnContext = true;
}
// Try your luck again
ctx = null;
continue;
// Not allowed reentrant call
//throw new RemoteException("Reentrant
call");
}
else
{
if (waitingOnContext) {
Logger.debug("FINISHED-LOCKING-WAITING
(CTX) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode());
waitingOnContext = false;
}
//We are in a home call so take the lock,
take it!
ctx.lock();
}
}
}
}
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
} while (ctx == null
Re: [JBoss-user] LOCKING-WAITING
You're may be getting such a performance hit because of all the
LOCKING-WAITING messages being sent to jboss/logs/server.log. Check out
that file, my guess it will be very, very large.
BTW, please don't remove that message. It is very useful for debugging
purposes.
Here's a fix for that very problem,
in org.jboss.ejb.plugins.EntityInstanceInterceptor I changed the invoke
method.
public Object invoke(MethodInvocation mi)
throws Exception
{
// The id store is a CacheKey in the case of Entity
CacheKey key = (CacheKey)mi.getId();
// Get cache
AbstractInstanceCache cache =
(AbstractInstanceCache)container.getInstanceCache();
Sync mutex = (Sync)cache.getLock(key);
EnterpriseContext ctx = null;
try
{
boolean waitingOnTransaction = false; // So we don't output
LOCKING-WAITING all the time
boolean waitingOnContext = false; // So we don't output
LOCKING-WAITING all the time
do
{
if (mi.getTransaction() != null &&
mi.getTransaction().getStatus() == Status.STATUS_MARKED_ROLLBACK)
throw new RuntimeException("Transaction marked for
rollback, possibly a timeout");
try
{
mutex.acquire();
// Get context
ctx = cache.get(key);
// Do we have a running transaction with the context
Transaction tx = ctx.getTransaction();
if (tx != null &&
// And are we trying to enter with another
transaction
!tx.equals(mi.getTransaction()))
{
// Let's put the thread to sleep a lock release
will wake the thread
// Possible deadlock
if (!waitingOnTransaction)
{
Logger.debug("LOCKING-WAITING (TRANSACTION)
for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+" tx:"+((tx == null) ?
"null" : tx.toString()));
waitingOnTransaction = true;
}
// Try your luck again
ctx = null;
continue;
}
else
{
if (waitingOnTransaction)
{
Logger.debug("FINISHED-LOCKING-WAITING
(TRANSACTION) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+"
tx:"+((tx == null) ? "null" : tx.toString()));
waitingOnTransaction = false;
}
// If we get here it's the right tx, or no tx
if (!ctx.isLocked())
{
//take it!
ctx.lock();
}
else
{
if (!isCallAllowed(mi)) {
// Go to sleep and wait for the lock to be
released
// This is not one of the "home calls" so
we need to wait for the lock
// Possible deadlock
if (!waitingOnContext) {
Logger.debug("LOCKING-WAITING (CTX)
for id "+ctx.getId()+" ctx.hash "+ctx.hashCode());
waitingOnContext = true;
}
// Try your luck again
ctx = null;
continue;
// Not allowed reentrant call
//throw new RemoteException("Reentrant
call");
}
else
{
if (waitingOnContext) {
Logger.debug("FINISHED-LOCKING-WAITING
(CTX) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode());
waitingOnContext = false;
}
//We are in a home call so take the lock,
take it!
ctx.lock();
}
}
}
}
catch (InterruptedException ignored) {}
finally
{
mutex.release();
}
} while (ctx == null);
// Set context on the method invocation
mi.setEnterpriseContext(ctx);
// Go on, you won
return getNext().invoke(mi);
}
catch (RemoteException e)
{
// Discard instance
// EJB 1.1 spec 12.3.1
cache.remove(key);
throw e;
} catch (RuntimeException e)
{
// Discard instance
// EJB 1.1 spec 12.3.1
cache.remove(key);
throw e;
} catch (E
RE: [JBoss-user] LOCKING-WAITING
it is not a deadlock it is normal synchronization... we must change that message marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dragan Milic |Sent: Tuesday, March 20, 2001 1:05 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-user] LOCKING-WAITING | | |Hello, | |i'm experiencing performance problems with jboss 2.1 under solaris: |when i'm using one BMP EJB cuncurrently from multiple threads it seems to |deadlock for a couple of seconds with following line reapeating in |server.log: | |[Category] LOCKING-WAITING (CTX) for id |CategoryPK(MUIKAQJkw34AAADfZiTtGJvA,de_DE) ctx.hash 6877805 | |cpu usage is 100% but calls to getXXX methods for that bean do not return |untill deadlock is resolved (it takes usually 2-10 secs for that) and |after that everything seems to be fine untill next deadlock occurs - bean |has Supports flag for transactions and ist not in a transaction context |while using, so i don't thing that the whole happends because of isolation |of transactions. | |Dragan. | | | | | |___ |JBoss-user mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
