Menu
▾
▴
Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException
|
From: Thomas R. <tho...@tr...> - 2005-03-23 13:53:41
|
Not sure whether this message ever made it to the list so here it is again: I think removing most of these are OK. Except, DataAccessResourceFailureException - is possible, I think. Connection could be lost during execution of a query. Reconnect and execute the query again is a possibility here. DataRetrievalFailureException indicates some kind of error retrieving column values - bad column index or column has been removed or renamed. Not recoverable, but could be worth reporting with this exception. It's not BadSqlGrammar and not DataIntegrityViolation. This is especially true when calling stored procedures where you don't specify the sql for the resultset that is generated. I think the above categories are worth keeping and we should gather error codes that represent these failures. If I could only have one of them, then DataRetrievalFailureException would be the one. Thomas On Mar 22, 2005, at 11:29 PM, Thomas Risberg wrote: > I think removing most of these are OK. > > Except, > > DataAccessResourceFailureException - is possible, I think. Connection > could be lost during execution of a query. Reconnect and execute the > query again is a possibility here. > > DataRetrievalFailureException indicates some kind of error retrieving > column values - bad column index or column has been removed or > renamed. Not recoverable, but could be worth reporting with this > exception. It's not BadSqlGrammar and not DataIntegrityViolation. > This is especially true when calling stored procedures where you don't > specify the sql for the resultset that is generated. > > I think the above categories are worth keeping and we should gather > error codes that represent these failures. If I could only have one > of them, then DataRetrievalFailureException would be the one. > > Thomas > > > On Mar 22, 2005, at 5:25 PM, Juergen Hoeller wrote: > >> Thomas, >> >> I've cleaned up the SQLErrorCodes class a little bit: there are no >> categories for OptimisticLockingFailureException, >> DataRetrievalFailureException and DataAccessResourceFailureException >> anymore. None of those should be caused by SQL error codes, but only >> by >> conditions at the ORM/DAO higher level (respectively connect failure >> in case >> of DataAccessResourceFailureException, which isn't indicated by a SQL >> error >> code either). >> >> I've also removed the category for >> PessimisticLockingFailureException. We >> generally don't offer fields for exception base classes in >> SQLErrorCodes but >> rather encourage specifying codes for fine-grained exception >> subclasses. We >> have fields for all three subclasses here: CannotAcquireLockException, >> DeadlockLoserDataAccessException (I've renamed the associated field >> to the >> shortened "deadlockLoserCodes") and >> CannotSerializeTransactionException. >> >> BTW, the latter exception isn't thrown anywhere currently. All others >> that >> we offer fields in SQLErrorCodes for are mapped for at least one >> database in >> the meantime. >> >> Strictly speaking, removing the SQLErrorCodes fields for those >> exceptions is >> not backwards-compatible. However, as we can't figure out how a >> database >> could cause them through error codes, this shouldn't matter; I think >> it's >> more important to offer a set of meaningful exception categories >> there. This >> should be acceptable for 1.2. And if someone unexpectedly found an >> error >> code for such a condition, it wouldn't be a bad thing to hear about >> it :-) >> >> Juergen >> >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...]On >> Behalf >> Of tho...@tr... >> Sent: Monday, March 21, 2005 4:22 PM >> To: spr...@li... >> Subject: Re: [Springframework-developer] >> DeadlockLoserDataAccessException vs CannotAcquireLockException >> >> >> >> I'm OK with PessimisticLockingFailureException as the superclass name. >> >> I wasn't questioning the existence of >> OptimisticLockingFailureException, I >> just >> can't come up with any SQLException error codes that would translate >> into >> it - >> it's not a SQL/Database error. It is definitely thrown by the >> ORM/DAO code. >> >> I can add this in later today, so we could make 1.2RC1. >> >> Thomas >> >> >> Quoting Juergen Hoeller <ju...@in...>: >> >>> FYI, we already do throw OptimisticLockingFailureException for >>> Hibernate >> and >>> JDO since the beginning of time :-) >>> >>> PessimisticLockingFailureException as superclass for >>> CannotAcquireLockException and co sounds appropriate to me. Do we >>> want to >>> include this in 1.2 RC1, which was originally scheduled for today? >>> ;-) It >>> looks like 1.2 RC1 won't be released before Wednesday anyway. >>> >>> Juergen >>> >>> >>> -----Original Message----- >>> From: spr...@li... >>> [mailto:spr...@li...]On >>> Behalf >>> Of Rod Johnson >>> Sent: Monday, March 21, 2005 3:00 PM >>> To: spr...@li... >>> Subject: Re: [Springframework-developer] >>> DeadlockLoserDataAccessException vs CannotAcquireLockException >>> >>> >>> Thomas >>> >>>> 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. >>> >>> I like this proposal. Though should it ben >>> PessimisticLockingFailureException to match >>> OptimisticLockingFailureException? Yes, the latter is intended to be >>> thrown by ORM tools, not JDBC-level operations. So we could convert >>> from >>> whatever the ORM tool throws. Or developers could throw it >>> themselves, >>> still allowing for consistent handling within Spring's DAO >>> abstraction. >>> >>> R >>>> >>>> Oracle might have these categories defined: >>>> '- CannotAquireLockException [X] >>>> '- CannotSerializeTransactionException [X] >>>> '- DeadlockLoserDataAccessException [X] >>>> >>>> while MySQL might have this >>>> '- TransactionLockingFailureException [X] >>> >>> >>> >>> ------------------------------------------------------- >>> 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 >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: 2005 Windows Mobile Application >> Contest >> Submit applications for Windows Mobile(tm)-based Pocket PCs or >> Smartphones >> for the chance to win $25,000 and application distribution. Enter >> today at >> http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > |
