InstantDB Project
About InstantDB
Project Mail Lists
Short History
Reporting Bugs
Screen Shots
3rd Party Examples
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

InstantDB: Odd Select Results



We're using InstantDB 3.10 on AIX 4.3.3 with JDK 1.1.8 and Jrun 2.3.3 and have created tables using the following commands:

CREATE TABLE Users (UserID CHAR(40) PRIMARY KEY UNIQUE, FirstName CHAR(30), LastName CHAR(30), Password CHAR(40) NOT NULL, Email CHAR(100), RepEmail CHAR(100), Enable INT NOT NULL, NewMessage INT, MsgDelivery INT)
CREATE TABLE UserAccount (UserID CHAR(40) NOT NULL FOREIGN KEY, AccountNumber CHAR(8) FOREIGN KEY)
CREATE TABLE Account (AccountNumber CHAR(8) PRIMARY KEY UNIQUE, Enable INT NOT NULL)

The database is populated through a web servlet-based interface via a JDBC connection. Essentially, users and accounts are set up and tied together via the UserAccount table. The servlet can be accessed by more than one user at the same time (concurrency issue?? ... not sure since there is only one JVM and the warnings in the documentation are for multiple JVM's).

Anyhow, we're seeing a rather odd situation that appears to occur at random in the database. The following "selects" from commsql return different result sets (even though they should be the same):

SELECT * FROM USERACCOUNT WHERE USERID='znc818712856'
returns
UserID, AccountNumber
Row 1:  znc818712856,18712856

SELECT * FROM USERACCOUNT WHERE ACCOUNTNUMBER='18712856'
returns
UserID,AccountNumber
Row 1:  znc818712856,18712856
Row 2:  znc818712856,18712856

Note that account number 18712856 is duplicated in the second select, but only shows up as such when selected by AccountNumber.

Also, when we try to delete by AccountNumber, only one of the duplicated rows is deleted. Another delete must be executed to get rid of the second (duplicate) row.

There are no indexes nor primary key defined for the UserAccount table.

Is this a possible concurrency issue with multiple sessions in a single JVM hitting the db at the same time??

Regards,

Chris