RE: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

I assume semantics like these, actually. But I guess it's quite hard to
discriminate these on the basis of SQL error codes, at least for some
databases.

I agree that it's probably best to throw CannotAcquireLockException for that
error code in SPR-733. There's always the option to customize, if someone
*really* needs more specific semantics.

Actually, if we play semantics gourmets here, shouldn't
DeadlockLoserDataAccessException be a subclass of
CannotAcquireLockException? After all, it's a lock that cannot be acquired
there, just for a specific reason...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Thomas Risberg
Sent: Sunday, March 20, 2005 5:46 PM
To: spr...@li...
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException


Just to be clear -- "CannotAcquireLockException" and
"DeadlockLoserDataAccessException" are semantically different.  You get
the "CannotAcquireLockException" when you request LOCK A NO WAIT and
someone else already has a lock on A.  You would get
"DeadlockLoserDataAccessException" when you LOCK A and try to LOCK B
while someone else did LOCK B and are now trying to LOCK A.  Someone
has to loose here or we have a deadlock.

I think we can just translate the deadlock exception to a
"CannotAcquireLockException" and allow anyone to add a custom exception
definition if they really want to have a
"DeadlockLoserDataAccessException" thrown.

We still need to review various databases for these types of codes - we
don't supply this in the default configuration.  It's currently left up
to the end-user to customize the sql-error-codes.xml if they care about
anything beyond the basic exceptions.  It would be worth it to add more
categories to the default sql-error-codes.xml.

Thomas

On Mar 20, 2005, at 11:19 AM, Juergen Hoeller wrote:

> Thomas, everybody,
>
> We've decided to have DeadlockLoserDataAccessException as a subclass of
> ConcurrencyFailureException in the meantime, but it's still unclear
> whether
> that MySQL error mentioned in SPR-733 should actually be translated to
> a
> CannotAcquireLockException or DeadlockLoserDataAccessException. The
> problem
> is that the exact semantics of those two exceptions are somewhat
> unclear...
>
> We currently throw CannotAcquireLockException in all such cases for
> other
> databases, so it would make sense to do this for that MySQL error too.
> But
> why does DeadlockLoserDataAccessException exist at all then? It
> currently
> isn't used anywhere ... Can we discrimate between a general "cannot
> acquire
> lock" error and the specific situation of the current process being a
> "deadlock loser"?
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Juergen Hoeller
> Sent: Tuesday, February 22, 2005 1:12 PM
> To: spr...@li...
> Subject: [Springframework-developer] DeadlockLoserDataAccessException
> vs
> CannotAcquireLockException
>
>
> Thomas, everybody,
>
> Please have a look at the following JIRA issue:
> http://opensource.atlassian.com/projects/spring/browse/SPR-733
>
> I agree that DeadlockLoserDataAccessException should be a subclass of
> ConcurrencyFailureException (which has been introduced in Spring 1.1),
> and
> have already changed this locally.
>
> However, DeadlockLoserDataAccessException isn't thrown anywhere;
> SQLErrorCodes does not support it. So as indicated in SPR-733, should
> we
> generally throw CannotAcquireLockException in such a case (which
> currently
> seems to happen for some databases, as defined in sql-error-codes.xml)?
> What's the semantic difference between those two exceptions, and is it
> worth
> keeping both?
>
> Juergen
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer