Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

OK, worth a reconsideration, I guess :-)

DataRetrievalFailureException is maybe too generic for associating it with
SQL error codes. It's mainly meant to be thrown by ORM tools or specific
DAOs, where domain entities with specific ids could not be found.

Maybe we should add a specific exception class that says "ResultSet access
failed", like "InvalidResultSetAccessException"? Such an exception should
probably be a subclass of InvalidDataAccessResourceUsageException, not of
DataRetrievalFailureException.

After all, such a failure is somewhat similar to BadSqlGrammarException: the
user probably specified an invalid column index or name, just like bad SQL
is probably the result of a user error too (selecting invalid columns or the
like).

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Thomas Risberg
Sent: Wednesday, March 23, 2005 5:52 AM
To: spr...@li...; Thomas Risberg
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException

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

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