Thank you for the information.
I am just looking onto a similar problem.
If I find an error I will send a message.
best regards
uwe

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Dienstag, 18. Februar 2003 09:16
> To: [EMAIL PROTECTED]
> Subject: Row not found by secondary key when simultanously updated
> 
> 
> 
> 
> Hi all,
> 
> I want to report some strange behaviour of the SAPDB database 
> that could be pointing
> towards some severe bug in the core database engine.
> 
> According to the official web site this is the correct place 
> to report it, so I give the
> essential details at once, in an anonymized manner.
> 
> We are building a complex application around a J2EE server 
> (currently JBoss 2.4.10) with
> SAPDB and alternatively Oracle as data storage machine. The 
> database is installed on a
> Windows NT server, the J2EE server is currently running on 
> our development machines
> (Windows 2000 + XP) when performing test runs, where the test 
> code is also being run.
> 
> From time to time we encounter "no data found" exceptions 
> when a row is accessed by the
> J2EE application (a finder method call of an EJB entity bean, 
> to be precise), which was
> very strange since the row affected was created long enough 
> before that moment that it
> should have been found, and most times it had already been 
> accessed successfully multiple
> times before.
> 
> Looking more closely at it (after activating the debug mode 
> of the "JAWS" persistence
> layer) we found that the problem occurred when the table was 
> accessed through a secondary
> key.
> 
> Before giving more details, I give an indication of the 
> general structure of the database
> table:
> 
> CREATE TABLE My_Table (
>     Primary_Key   DECIMAL(19),
>     -- other column definitions
>     Other_Column  BOOLEAN,
>     Secondary_Key CHAR(32),
> 
>     PRIMARY KEY (Primary_Key),
>     -- other constraints
>     CONSTRAINT Constraint_Name UNIQUE Secondary_key
> );
> 
> 
> Looking up and down the log file I found an insteresting 
> conincidence: every time the
> table access failed the sequence of events was this:
> (1) the statement "SELECT ID FROM My_Table WHERE 
> Secondary_Key = ?" is prepared and
> (probably) executed
> (2) the statement "UPDATE My_Table SET Other_Column = ? WHERE 
> Primary_Key = ?" is executed
> from another thread (presumably using the same JDBC 
> DataSource), modifying a boolean
> column with no index or constraint on it
> (3) the ResultSet of the statement (1) is examined and found 
> to be empty.
> 
> There are typically around 400 ms between events (1) and (2) 
> and a varying amount of time
> between (2) and (3). That's what happened using a SAPDB 7.3.0.
> 
> To counter-check, I tested the same application with an 
> Oracle as database and found
> nothing like this behaviour.
> 
> As a third test, we installed a SAPDB 7.4.3 and repeated the 
> test. Same result as on
> 7.3.0, but the log file has an interesting difference as the 
> sequence of events now is
> first (2), second (1) and (3), occurring between 40 and 400 
> ms after (2).
> 
> This malbehaviour did not change either when we moved from 
> SAPDB-JDBC 7.3.0 (build 029) to
> 7.4.4 (build 001).
> 
> One additional observation: it could be true that for the 
> problem to manifest various test
> runs are required with no database clean-up after each test 
> run, so the affected table
> already contains about 5 to 10 rows when the problem occurs. 
> But this is not completely
> proven by now.
> 
> Best regards
> Arne Siegel
> 
> 
> _______________________________________________
> sapdb.general mailing list
> [EMAIL PROTECTED]
> http://listserv.sap.com/mailman/listinfo/sapdb.general
> 
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general

Reply via email to