Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

Well, I agree too. I'm mainly pointing out that we're currently not throwing
DeadlockLoserDataAccessException anywhere :-)

BTW, I still think DeadlockLoserDataAccessException should be a subclass of
CannotAcquireLockException. From the client's point of view, being a
deadlock loser is a special form of having been unable to acquire a lock. It
seems to me that, in most cases, a client cannot react more specifically to
a deadlock loser sitation than it can to having been unable to acquire a
lock.

Fine-granular exceptions are fine, of course, but I guess the main driver
should be the needs of data access client code. If client code is unable to
react specifically, it's arguably good enough to discriminate actual failure
causes through the exception message. On the other hand, there are always
special clients with special needs...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Monday, March 21, 2005 10:31 AM
To: spr...@li...
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException


I agree with Thomas on all points. It *is* possible to find out about
deadlock conditions in most decent databases AFAIK, but it requires
non-standard codes. (SQLState codes don't help IIRC.)

I think we need to improve significantly in the error codes/categories.
We have a fantastically powerful concept there: we're not making full
use of it.

Thomas Risberg wrote:
> 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
>

--
Rod Johnson
Interface21 - Spring Services from the Source
http://www.springframework.com

Founder, Spring Framework:
http://www.springframework.org

Author, "Expert One-on-One J2EE Development Without EJB"
(May 2004, with Juergen Hoeller).
http://www.amazon.com/exec/obidos/ASIN/0764558315/

Author, "Expert One-on-One J2EE Design and Development"
(October 2002).
http://www.amazon.com/exec/obidos/tg/detail/-/0764543857/


____________________________________________________
Interface21 Limited
Registered Office Summit House, 2-2a Highfield Road, Dartford, Kent DA1 2JY
Registered in England and Wales No. 5187766
____________________________________________________



-------------------------------------------------------
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