Agreed. Any number of exceptions can occur when you commit, regardless
of what queries you've run in the same transaction. That's the nature
of multi-user systems, unless of course you want to set the
transaction isolation level to serialize (not usually recommended).
As for using onValidate() versus onSuccess(), I'd avoid doing anything
but page navigation in onSuccess() because ionSuccess() can't report
exceptions properly (https://issues.apache.org/jira/browse/
TAPESTRY-1972).
On 13/09/2009, at 4:13 PM, Hilco Wijbenga wrote:
2009/9/12 Thiago H. de Paula Figueiredo <thiag...@gmail.com>:
Em Sat, 12 Sep 2009 17:38:43 -0300, Bruno Santos
<bitbet...@gmail.com>
escreveu:
Well, even if i do:
league = new League();
league.setName("repeated name");
Unique constraints like this should be checked by you *before*
sending an
insert or update to the database.
Would that not simply create a race condition? Thread A checks XYZ,
thread B (checks and) writes XYZ, thread A tries to write XYZ and
BOOM.
Shouldn't database constraint checking be a job for the database, not
for the application? The right tool for the job and all that. :-)
(That doesn't mean you can't check prior to inserting/updating but you
should never *rely* on it.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
