Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Rod J. <ro...@in...>]

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
____________________________________________________