MMBase

DatabaseStorage.createKey() not thread-safe

Details

  • Type: Bug Bug
  • Status: In Progress In Progress
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.7.0
  • Fix Version/s: 2.0.0
  • Component/s: Database Layer
  • Description:
    Hide
    original bugid: #6307
    The createKey() method does 2 SQL queries; but another thread can be executing the same code simultaniously: that will result in 2 threads receiving the same objectnumber for their new object.

    Solution: use synchronization; or better: use table locking
    Added synchronization to createKey() and createSequence().
    This will not solve potential problems with cross-server MMBases, but will solve it for edits within one MMBase instance.
    Solving cross-server will include some method of locking, which is not a SQL92 standard, en is in several databases either not or poorly implementented, or breaks transactions:

    Postgresql:
    Locking a table lasts a whole transaction. Fortunately, Postgresql does not need lcoking as sequence update/retrieveal is done in one statement.

    Mysql:
    LOCK TABLES statement closes a transaction (say bye bye to rollback), and is only supported in MySQL 4,0 or higher.

    Hsqldb:
    Supports no locking

    Informix:
    unknown


    Show
    original bugid: #6307 The createKey() method does 2 SQL queries; but another thread can be executing the same code simultaniously: that will result in 2 threads receiving the same objectnumber for their new object. Solution: use synchronization; or better: use table locking Added synchronization to createKey() and createSequence(). This will not solve potential problems with cross-server MMBases, but will solve it for edits within one MMBase instance. Solving cross-server will include some method of locking, which is not a SQL92 standard, en is in several databases either not or poorly implementented, or breaks transactions: Postgresql: Locking a table lasts a whole transaction. Fortunately, Postgresql does not need lcoking as sequence update/retrieveal is done in one statement. Mysql: LOCK TABLES statement closes a transaction (say bye bye to rollback), and is only supported in MySQL 4,0 or higher. Hsqldb: Supports no locking Informix: unknown

Activity

Hide
Johannes Verelst added a comment - 2004-02-03 17:51
DatabaseStorage.createKey() not thread-safe
The createKey() method does 2 SQL queries; but another thread can be executing the same code simultaniously: that will result in 2 threads receiving the same objectnumber for their new object.

Solution: use synchronization; or better: use table locking
Show
Johannes Verelst added a comment - 2004-02-03 17:51 DatabaseStorage.createKey() not thread-safe The createKey() method does 2 SQL queries; but another thread can be executing the same code simultaniously: that will result in 2 threads receiving the same objectnumber for their new object. Solution: use synchronization; or better: use table locking
Hide
Pierre van Rooden added a comment - 2004-02-04 10:05
DatabaseStorage.createKey() not thread-safe
The createKey() method does 2 SQL queries; but another thread can be executing the same code simultaniously: that will result in 2 threads receiving the same objectnumber for their new object.

Solution: use synchronization; or better: use table locking
Added synchronization to createKey() and createSequence().
This will not solve potential problems with cross-server MMBases, but will solve it for edits within one MMBase instance.
Solving cross-server will include some method of locking, which is not a SQL92 standard, en is in several databases either not or poorly implementented, or breaks transactions.
Show
Pierre van Rooden added a comment - 2004-02-04 10:05 DatabaseStorage.createKey() not thread-safe The createKey() method does 2 SQL queries; but another thread can be executing the same code simultaniously: that will result in 2 threads receiving the same objectnumber for their new object. Solution: use synchronization; or better: use table locking Added synchronization to createKey() and createSequence(). This will not solve potential problems with cross-server MMBases, but will solve it for edits within one MMBase instance. Solving cross-server will include some method of locking, which is not a SQL92 standard, en is in several databases either not or poorly implementented, or breaks transactions.
Hide
Pierre van Rooden added a comment - 2004-02-04 10:26
DatabaseStorage.createKey() not thread-safe
The createKey() method does 2 SQL queries; but another thread can be executing the same code simultaniously: that will result in 2 threads receiving the same objectnumber for their new object.

Solution: use synchronization; or better: use table locking
Added synchronization to createKey() and createSequence().
This will not solve potential problems with cross-server MMBases, but will solve it for edits within one MMBase instance.
Solving cross-server will include some method of locking, which is not a SQL92 standard, en is in several databases either not or poorly implementented, or breaks transactions.
Show
Pierre van Rooden added a comment - 2004-02-04 10:26 DatabaseStorage.createKey() not thread-safe The createKey() method does 2 SQL queries; but another thread can be executing the same code simultaniously: that will result in 2 threads receiving the same objectnumber for their new object. Solution: use synchronization; or better: use table locking Added synchronization to createKey() and createSequence(). This will not solve potential problems with cross-server MMBases, but will solve it for edits within one MMBase instance. Solving cross-server will include some method of locking, which is not a SQL92 standard, en is in several databases either not or poorly implementented, or breaks transactions.

People

Dates

  • Created:
    2004-02-04 10:43
    Updated:
    2009-07-31 16:15