Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Thomas R. <tho...@tr...>]

Spending some more time on this I think we should add another layer to 
the pessimistic/transaction concurrency exceptions.  The conurrency 
exceptions are the ones that can be handled in code and retried, so we 
should try to provide as much detail as possible here.  The only one we 
have in sql-error-codes.xml right now is CannotAquireLockException for 
Oracle.

ConcurrencyFailureException
'- TransactionLockingFailureException [X]
     '- CannotAquireLockException [X]
     '- CannotSerializeTransactionException [X]
     '- DeadlockLoserDataAccessException [X]
'- OptimisticLockingFailureException [X?]

The [X] indicates that I think we should provide the option for 
separate categories in sql-error-codes.xml for this exception.  Some of 
the lower exception classes might not make sense for all databases, but 
TransactionLockingFailure and OptimisticLockingFailure will provide 
enough information to retry the transaction if the app developer want 
to do that.

Oracle might have these categories defined:
     '- CannotAquireLockException [X]
     '- CannotSerializeTransactionException [X]
     '- DeadlockLoserDataAccessException [X]

while MySQL might have this
'- TransactionLockingFailureException [X]

If we introduce a common base class for the pessimistic exception, then 
this would be possible.

We have the OptimisticLockingFailureExecption as a separate category - 
I can't remember why.  Do we have any examples of error codes that 
would indicate this.  The way I see it, this is the type of exception 
an ORM layer would throw.

Thomas


On Mar 21, 2005, at 4:55 AM, Rod Johnson wrote:

>> 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...
> I think we should capture more information. It IS possible. Exception 
> messages are only useful for logging: they're useless to calling code.
>
> The beauty of using exception subclasses is that the client needs to 
> worry only to whatever granularity they choose. So nothing is lost by 
> having the finer-grained classes (assuming they do get thrown). There 
> definitely are situations where knowing about deadlocks makes a lot of 
> sense--for example, consider adding an aspect that logged the 
> frequency of deadlocks and the context, to help in correcting a design 
> flaw. And I've seen applications where people needed to find out about 
> deadlocks, for whatever reason.
>
> R
>
>
>
> -------------------------------------------------------
> 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
>
>