SCJP 1.4 - 83%, SCJD 360-90%,
ITeezy.com
Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Apparently - and I am giving away half the solution here - two competing threads running the create method may overwrite the same record!!!
SCJP 1.4, SCJD 1.4, SCWCD 1.3, ICSD:Websphere 5.1
Originally posted by Anton Golovin:
Apparently - and I am giving away half the solution here - two competing threads running the create method may overwrite the same record!!!
"Large Vehicles Require More Room" - Highway 69 en route to Sudbury, Ontario
Originally posted by Anton Golovin:
Hi, Matej!
I would agrue very strongly against not using DuplicateKeyException. The create method, if implemented incorrectly, may cause the 44/80 locking score. DubplicateKeyException solves the problem. It is not the only way to solve the problem, but it is the preferred way to solve the problem.
Apparently - and I am giving away half the solution here - two competing threads running the create method may overwrite the same record!!!
Hope this helps.
SCJP 1.4, SCJD 1.4, SCWCD 1.3, ICSD:Websphere 5.1
Two competing threads on a create() should not get the same record number assigned (this part you have correct). But when you do not use primary keys it has nothing to do with the DuplicateKeyException. You probably endup solving this by implementing the propper synchronization on the read/write and the propper synchronization on the system responsible for determining the next record number. So, when using no primary keys, you should not throw DuplicateKeyException.
To answer the TS his question; I don't think you should make it deprecated either. Deprecated means something may not be used anymore because it is replaced by something else or it should not be used anymore because the use of it is dangerous. This is not the case with the DuplicateKeyException, it is a valid and crucial exception of every normal db implementation. I even think that in the future B&S will implement it when the extend it to deal with primary keys.
SCJP 1.4 - 83%, SCJD 360-90%,
ITeezy.com
SCJP 1.4<br />SCJD (in progress)
When implementing primary keys, please keep this scenario in mind:
1. Thread1: create() record {a,b,c} with primary key {a,b}
2. Thread1: create() searches database for primary key
3. Thread1: create() result is false (does not exist)
4. Thread2: update() record {z,b,x} to {a,b,x}
5. Thread2: update() search database to see if this pk allready exists
6. Thread2: update() result is false (does not exist)
7. Thread2: update() commit update to file
8. Thread1: create() commit create to file
So in db you have: {a,b,c} and {a,b,c} . The primary is duplicate here, and this should never happen. The correct way would be that the create() or the update() (depending who is first) throw the DuplicateKeyException.
B.S. University of Wisconsin<br />SCJP 1.4 (85%)<br />SCJD 1.4 (92%) B&S Contractors
I'm also doing UrlyBird, concerning the create and delete method's in the data interface wich my client isn't using, does throwing an UnsuportedOperationException count as implementing? If so, is this acceptable?
SCJP 1.4 - 83%, SCJD 360-90%,
ITeezy.com
SCJP 1.4 - 83%, SCJD 360-90%,
ITeezy.com
Originally posted by Jared Chapman:
Just an idea this discussion led me to brainstorm. The update method doesn't throw a DuplicateKeyException, but should it? When choosing fields that make up the primary key, you choose fields that identify the record as unique, and the fields should not be expected to change. For example, the owner field is the worst possible field to be a primary key, because we expect its value to change. So why not prevent updating a record's primary key fields, and instead instruct the caller to delete the record and create a new one? Just an idea, please feel free to tear it apart.
SCJP 1.4<br />SCJD 1.4
If you have a bad day in October, have a slice of banana cream pie. And this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|