Skip to Content
author's profile photo Former Member
Former Member

communication hangs on Vwait

Hi all,

i get again the blocked threads, but now maybe i found some reason, using:

x_cons DBNAME sh ac 1 i get:

SERVERDB: DBNAME

T115   7     -1 User         0* Vwait                 0 0               187962245(s)
T121   7     -1 User         0* Vwait                 0 0               187962245(s)
T125   7     -1 User         0* Vwait                 0 0               187962245(s)
T142   7     -1 User         0* Vwait                 0 0               187962245(s)
T193   7     -1 User         0* Vwait                 0 0               187962245(s)
T214   7     -1 User         0* Vwait                 0 0               187962245(s)
T222   7     -1 User         0* Vwait                 0 0               187962245(s)
T239   8     -1 User         0* Vwait                 0 0               191206909(s)
T252   8     -1 User         0* Vwait                 0 0               191206909(s)
T257   8     -1 User         0* Vwait                 0 0               191206909(s)
T276   8     -1 User         0* Vwait                 0 0               191206909(s)
T287   8     -1 User         0* Vwait                 0 0               191206909(s)
T304   8     -1 User         0* Vwait                 0 0               191206909(s)
T312   8     -1 User         0* Vwait                 0 0               191206909(s)
T324   8     -1 User         0* Vwait                 0 0               191206909(s)
T335   8     -1 User         0* Vwait                 0 0               191206909(s)
T360   9     -1 User         0* Vwait                 0 0               192723529(s)
T388   9     -1 User         0* Vwait                 0 0               192723529(s)
T400   9     -1 User         0* Vwait                 0 0               192723529(s)
T418   9     -1 User         0* Vwait                 0 0               192723529(s)
T459   9     -1 User         0* Vwait                 0 0               192723529(s)
T466   9     -1 User         0* Vwait                 0 0               192723529(s)
T475  10     -1 User         0* Vwait                 0 0               185005529(s)
T486  10     -1 User         0* Vwait                 0 0               185005529(s)
T493  10     -1 User         0* Vwait                 0 0               185005529(s)
T497  10     -1 User         0* Vwait                 0 0               185005529(s)
T503  10     -1 User         0* Vwait                 0 0               185005529(s)
T505  10     -1 User         0* Vwait                 0 0               185005529(s)
T507  10     -1 User         0* Vwait                 0 0               185005529(s)
T513  10     -1 User         0* Vwait                 0 0               185005529(s)
T531  10     -1 User         0* Vwait                 0 0               185005529(s)
T532  10     -1 User         0* Vwait                 0 0               185005529(s)
T534  10     -1 User         0* Vwait                 0 0               185005529(s)
T549  10     -1 User         0* Vwait                 0 0               185005529(s)
T561  10     -1 User         0* Vwait                 0 0               185005529(s)
T575  10     -1 User         0* Vwait                 0 0               185005529(s)
T582  10     -1 User         0* Vwait                 0 0               185005529(s)
T584  10     -1 User         0* Vwait                 0 0               185005529(s)

checking Server side i get the Stack that is waiting on socketRead that blocks the Finalizer:

"http-80-10" daemon prio=10 tid=0x0000002af5750800 nid=0x7b9b runnable [0x000000004b853000..0x000000004b854c30]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at com.sap.dbtech.rte.comm.BasicSocketComm.receiveData(BasicSocketComm.java:577)
        at com.sap.dbtech.rte.comm.BasicSocketComm.receive(BasicSocketComm.java:666)
        at com.sap.dbtech.rte.comm.JdbcCommunication.execute(JdbcCommunication.java:41)
        at com.sap.dbtech.jdbc.ConnectionSapDB.execute(ConnectionSapDB.java:536) 
        - locked <0x0000002aa7c55c60> (a com.sap.dbtech.jdbc.ConnectionSapDB)
        at com.sap.dbtech.jdbc.ConnectionSapDB.execute(ConnectionSapDB.java:461)
        at com.sap.dbtech.jdbc.CallableStatementSapDB.execute(CallableStatementSapDB.java:441)
        at com.sap.dbtech.jdbc.CallableStatementSapDB.execute(CallableStatementSapDB.java:313)
        at com.sap.dbtech.jdbc.CallableStatementSapDB.executeUpdate(CallableStatementSapDB.java:778)
        at com.sap.dbtech.jdbc.trace.PreparedStatement.executeUpdate(PreparedStatement.java:81)
        at org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102)
        at org.exolab.castor.jdo.engine.SQLEngine.create(SQLEngine.java:616)
        at org.exolab.castor.jdo.engine.SQLEngine.create(SQLEngine.java:536)
        at org.exolab.castor.jdo.engine.SQLEngine.create(SQLEngine.java:536)
        at org.exolab.castor.persist.ClassMolder.create(ClassMolder.java:891)
        at org.exolab.castor.persist.LockEngine.create(LockEngine.java:458)
        at org.exolab.castor.persist.TransactionContext.create(TransactionContext.java:803)
        - locked <0x0000002aa9dfbd38> (a org.exolab.castor.jdo.engine.TransactionContextImpl)
        at org.exolab.castor.jdo.engine.DatabaseImpl.create(DatabaseImpl.java:338)
        at com.supridatta.bean.DataPersist.gravar(DataPersist.java:215)

and here is the Finalizer BLOCKED:

"Finalizer" daemon prio=10 tid=0x0000002af1e04800 nid=0x4a5a waiting for monitor entry [0x0000000041531000..0x0000000041531c30]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.sap.dbtech.jdbc.StatementSapDB.closeResultSet(StatementSapDB.java:189)
        - waiting to lock <0x0000002aa7c55c60> (a com.sap.dbtech.jdbc.ConnectionSapDB)
        at com.sap.dbtech.jdbc.StatementSapDB.close(StatementSapDB.java:174)
        at com.sap.dbtech.jdbc.CallableStatementSapDB.close(CallableStatementSapDB.java:2325)
        at com.sap.dbtech.jdbc.trace.PreparedStatement.close(PreparedStatement.java:637)
        at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.close(DelegatingStatement.java:168)
        at org.exolab.castor.jdo.engine.SQLEngine$SQLQuery.close(SQLEngine.java:1675)
        at org.exolab.castor.persist.QueryResults.close(QueryResults.java:241)
        at org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.close(OQLQueryImpl.java:676)
        at org.exolab.castor.jdo.engine.OQLQueryImpl$OQLEnumeration.finalize(OQLQueryImpl.java:685)
        at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
        at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
        at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
        
   Locked ownable synchronizers:
        - None

anyway to check what causes that Vwait, but a way to check just when that occurs, because i cant manage to create or simulate that problem, that just occurs in a random time, maybe occurs one per week, one per month, etc...

any idea are welcome.

best regards

Clóvis

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on May 19, 2009 at 06:21 AM

    Hallo,

    you are familiar with the select-option to specify the isolation level?

    If at least for the select of SYSPARSEID you would use ISOLATION LEVEL 0, every lock and check for locks on this table would be avoided. ANd I think, especially for this table, no locks during select are needed.

    But even with the ISOLATION LEVEL 1 (usually the default), one would not lock the table, just check if the row currently handled is exclusive locked by another task. Please check the statement (add that option ISOLATION LEVEL ...) and check if this change will help.

    Elke

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi, Elke

      i used the lock ISOLATION LEVEL 0 but still getting:

      118:  * W1  User task 338 is waiting in state Command wait for page 59552, locked from task 520

      at time when this analyses was taken i stoped using my tool, then perhaps, maybe command monitor was locking or waiting to insert commands in SYSPARSEID table, like a queue?

      thanks for your tip

      Clóvis

  • Posted on Apr 29, 2009 at 02:11 PM

    Hi Clovis,

    please provide a

    x_cons <SID> show all
    

    output the next time this issue occurs.

    regards,

    Lars

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Lars Breddemann

      Hi Lars,

      i'm ending this thread too much work was done, i must review how application works with maxdb and create my own database controller at application side. For now help from Elke help me too, in SELECT statements that i cant avoid TABLE LOCKS, using ISOLATION LEVEL 0 solved, that problems that INSERT on table TITULOPAGAMENTO waits until a long analysis SELECT ends.

      in time, when you discover if there is a way for the OpenSource side contract some support in MaxDB database i will appreciate to know how, because i think that in some cases, only an specialist can point what is wrong with database or with application.

      thanks for all help and time spend.

      best regards

      Clóvis

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.