Hi Arne, a correction is submitted in 73,743,744 and will be available in the next builds or you can check it out via cvs for V74-develop tonight. regards Uwe
> -----Original Message----- > From: Hahn, Uwe > Sent: Dienstag, 18. Februar 2003 10:36 > To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] > Subject: RE: Row not found by secondary key when simultanously updated > > > 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 > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
