:: The unique constraint on the FK Destination in Items means
:: that, if Item A points to destination B, then no other row
:: in the Items table can point its destination to destination

Yes, exactly. It's a 1:1 but they start out with 1:0 (null) until a certain
condition occurs.

:: If that was your intention, then as soon as the first
:: transaction assigns an item to Destination B, no other item
:: can be assigned to that destination unless the first
:: transaction changes its mind, rolls back the change and once

If its committed. But the two transactions may try to run at the same time.
In which case I would prefer to not just run up against the constraint
(Although this may be the only option) and move on and "fetch" the next
record to use.

:: again frees that destination for use by another item. Even
:: within the
:: *same* transaction, if you have one item pointing at that

But lets say I have A and B. A finds a record, but has not committed its
changes yet. At the same time, B finds a record. Wont B find the same
"unused" record that A did since A has not commited its changes yet? I guess
maybe its an option to monkey with the transaction options on this one
instance so they see each others changes. Id have to run it then in separate
connection to ensure that it wouldn't be "nested". (The framework handles
nesting by "ignoring" inner transactions)

:: Can't exactly grokk what you mean by "claim". If one
:: transaction is able to post a change to a row, it secures a
:: lock on the entire row. Any another transaction that
:: requests a change to the same row (or any row that depends
:: on that row) after that, will fail with a lock conflict.

Yes - Im trying to either detect this, or head it off sooner so that I don't
even still see this record as having a null in the FK.

:: Resolving conflicts is what multi-user programming is about.
:: Don't be frightened of concurrency exceptions - they are
:: the channel through which applications get to know about
:: conflicts. How the conflict resolves is up to you to decide.
:: For example, trap the lock conflict exception, cancel the
:: request and make another one...and repeat until it succeeds.

Its not the handling of the DB Im worried about - its catching specific
exceptions when I don't know exactly where they will occur. I cant just
"generically" back out, but want to know when this exact thing happens so I
can then move to the next record. That is Im trying to catch this situation
as early up the pipe as I can.