Menu
▾
▴
Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException
|
From: Thomas R. <tho...@tr...> - 2005-03-23 04:52:41
|
If we decide to keep DataRetrievalFailureException -- one code for Oracle is '17003' [Invalid column index]. 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 >> >> > |
