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
