Where's my Derby?
in [Java Programming]
|
Prev: how to record screen acrtions programatically?
Next: Build A Home Internet Business For Extra Income Stream
From: Andreas Leitgeb on 7 Apr 2010 08:58 Arne Vajhøj <arne(a)vajhoej.dk> wrote: > Especially with a high update ratio then an UPDATE with a WHERE > and only an INSERT if no rows were updated could be worth > considering. Would it be safe? Or could one end up with two entries for that key, if the attempted updates happen at the same time? (Ok, two equal keys could be prevented by unique-key-constraints, but then it would mean that the "last" one doesn't always win, but may possibly run into an DB-error, instead...)
From: John B. Matthews on 7 Apr 2010 14:34 In article <4bbbfc63$0$5025$9a6e19ea(a)unlimited.newshosting.com>, Wayne <nospan(a)all.invalid> wrote: [...] > Just a follow-up: I copied the installer I used, to a Windows XP > 32-bit host at work, and ran it there. It does show JavaDB! But > it doesn't when run on my home system! Using <http://java.sun.com/javase/downloads/index.jsp> JDK 6 Update 19, I see the same result: JavaDB is offered by default on Windows 7 Ultimate but not even listed on Windows 7 Home Premium. > So, my best guess is that the installer is examining the system for > JavaDB compatibility, doesn't like what it sees, and doesn't offer > to install it. Either that, or I have a broken (or virus-infected) > system at home. > > I never did like the JDK installer. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Martin Gregorie on 7 Apr 2010 14:35 On Wed, 07 Apr 2010 12:58:26 +0000, Andreas Leitgeb wrote: > Arne Vajhøj <arne(a)vajhoej.dk> wrote: >> Especially with a high update ratio then an UPDATE with a WHERE and >> only an INSERT if no rows were updated could be worth considering. > > Would it be safe? Or could one end up with two entries for that key, > if the attempted updates happen at the same time? > Should be OK provided you use explicit commit units rather than default automatic commits. > (Ok, two equal keys could be prevented by unique-key-constraints, but > then it would mean that the "last" one doesn't always win, but may > possibly run into an DB-error, instead...) > If both statements are in the same commit unit and you're using row or page locking and a sensible lock timeout, the second update attempt should wait until the first update commits and then report that the row exists. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Andreas Leitgeb on 7 Apr 2010 17:11 Martin Gregorie <martin(a)address-in-sig.invalid> wrote: > On Wed, 07 Apr 2010 12:58:26 +0000, Andreas Leitgeb wrote: >> Arne Vajhøj <arne(a)vajhoej.dk> wrote: >>> Especially with a high update ratio then an UPDATE with a WHERE and >>> only an INSERT if no rows were updated could be worth considering. >> Would it be safe? Or could one end up with two entries for that key, >> if the attempted updates happen at the same time? > Should be OK provided you use explicit commit units rather than default > automatic commits. "Should be ..." doesn't really sound too convincing in the context of possible concurrency problems ;-) > If both statements are in the same commit unit and you're using row or > page locking ... Which row or page would be locked, if the where-clause didn't match anything? The whole table?
From: Lew on 7 Apr 2010 17:46
Arne Vajhøj wrote: >>>> Especially with a high update ratio then an UPDATE with a WHERE and >>>> only an INSERT if no rows were updated could be worth considering. Andreas Leitgeb wrote: >>> Would it be safe? Or could one end up with two entries for that key, >>> if the attempted updates happen at the same time? Martin Gregorie wrote: >> Should be OK provided you use explicit commit units rather than default >> automatic commits. Andreas Leitgeb wrote: > "Should be ..." doesn't really sound too convincing in the context of > possible concurrency problems ;-) If the database engine supports transactions and you remember to use them, it will be safe. Martin Gregorie wrote: >> If both statements are in the same commit unit and you're using row or >> page locking ... Andreas Leitgeb wrote: > Which row or page would be locked, if the where-clause > didn't match anything? The whole table? That depends on the database engine you use and whether the database is partitioned. RTFM for your particular environment. It also depends on whether there are sequenced keys in the table. I worked on a project a couple of years back that had many tables sharing the same sequence for their keys. It caused huge contention because every table's INSERT had to wait for the sequence to unlock, and there were a lot of INSERTs. Another trick to consider is judicious use of SELECT ... FOR UPDATE. -- Lew |