Hi,    (re-sent to put on mailing list)

Thanks for getting back,  ok.

There are no deletes in this instance, and also no inserts.  Under normal
circumstances, I would do an insert if the last "select" returned no rows,
but that was in effect resetting an existing property with this problem.

The final select gets an empty result set (I only expect one row), I have
since tried 

SELECT
SELECT FOR UPDATE
SELCTE FOR UPDATE
UPDATE
COMMIT

With the same result.


When it happens there would actually usually be 10 separate connections,
each processing up to 30 transactions per second.
It also might take a few hours for the problem to occur once I enable the
vtrace, is this a problem?

Also many transactions would turn off the vtrace, I assume this wont affect
it? As once the first one does it we should have the vtrace?


Please let me know if putting in the vtrace with so many things going on
will be useful, and I'll put it in.



Regards
Michael Andrewes


 

-----Original Message-----
From: Schroeder, Alexander [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 19 January 2005 6:21 PM
To: Michael Andrewes
Subject: RE: Row locking problem.

Hello Michael,
getting back to your original mail ...
 
> > (one connection)
> >     1. select " + fieldNames() + " FROM " + TABLE_NAME + " WHERE
> > promotion_id = ?    (other properties are used initially in parts of
> some
> > application)

> select " + fieldNames() + " FROM " + TABLE_NAME + " WHERE 
> property_name = ?
> and promotion_id = ? FOR UPDATE OF property_value

> 
> >     3.1 select " + fieldNames() + " FROM " + TABLE_NAME + " WHERE 
> > promotion_id = ?

> >     3.2 update " + TABLE_NAME + " set property_value = ? where 
> > property_name = ? and promotion_id = ?

> > (commit)

So basically you do:

SELECT
SELECT FOR UPDATE
SELECT
UPDATE
COMMIT

Second, there are no INSERTS or DELETES here, just UPDATES, am I right?

Which of the SELECTs gets the 'empty row' and how does this manifest - means
empty row that the result set is empty, or do you really mean the value is
garbled? (I.e. some fields are there and the 'property'
value you speaking of contains nothing/some garbage/wrong value?

As you say there are only two sessions taking part, you may create possibly
simply a VTRACE:

----------------------------------------------------------

1) Start the trace: dbmcli -d <dbname> -u <dbm,dbm> util_execute diagnose
vtrace default on 

2) Insert into your code in the place where you log that 'an empty row has
been found'
   a statement executing the command "DIAGNOSE VTRACE DEFAULT OFF", so that
we can catch
   the situation.

3) Flush the trace: dbmcli -d <dbname> -u <dbm,dbm> 
   util_execute diagnose vtrace flush or more simply dbmcli -d <dbname> -u
<dbm,dbm> trace_flush 

4) Create the text representation: dbmcli -d <dbname> -u <dbm,dbm>
trace_prot akb 

5) Copy the text representation to a local file: 
   dbmgetf -d <dbname> -u <dbm,dbm> -k KNLTRCPRT -f <local file name> 

You may then possibly want to send the trace ... 

Regards
Alexander Schr�der
SAP DB, SAP Labs Berlin


--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to