springframework-developer

[Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Pierre B. <pie...@gm...>]

Hi Juergen,

In our project, we use an implementation of SQLExceptionTranslator  to
translate sybase error code '1205' in
DeadlockLoserDataAccessException.

From sybase documentation:

"This error occurs when a process tries to acquire a lock on an object
that is locked by a second process when the second process is waiting
for a lock on an object that has been locked by the first process.
This situation is a deadlock, and can involve more than two processes.

Adaptive Server detects this situation, rolls back the transaction
that has accumulated the least amount of CPU time, and notifies the
application program of this action with Error 1205. This allows the
other users' processes to move forward."

We catch the DeadlockLoserDataAccessException in an ExceptionHandler
and display a warning to user.

Hope this helps.

Pierre

On Tue, 22 Feb 2005 13:12:23 +0100, Juergen Hoeller
<ju...@in...> wrote:
> 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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

I think it makes sense to have DeadlockLoserDataAccessException being a subclass
of ConcurrencyFailureException.  Then you would only have to catch this
exception before retrying the operation.

The esiest way to handle this in the translation is to set the
"customTranslations" property on the "SQLErrorCodes" like:

<bean id="Sybase" class="org.springframework.jdbc.support.SQLErrorCodes">
...
  <property name="badSqlGrammarCodes">
  ...
  </property>
  <property name="dataIntegrityViolationCodes">
  ...
  </property>
  ...
  <property name="customTranslations">
    <list>
      <bean
        class="org.springframework.jdbc.support.CustomSQLErrorCodesTranslation">
        <property name="errorCodes">
          <value>1205</value></property>
        <property name="exceptionClass">
         
<value>org.springframework.dao.DeadlockLoserDataAccessException</value>
        </property>
      </bean>
    </list>
  </property>
  ...
</bean>


Thomas



Quoting Pierre Bittner <pie...@gm...>:

> Hi Juergen,
>
> In our project, we use an implementation of SQLExceptionTranslator  to
> translate sybase error code '1205' in
> DeadlockLoserDataAccessException.
>
> >From sybase documentation:
>
> "This error occurs when a process tries to acquire a lock on an object
> that is locked by a second process when the second process is waiting
> for a lock on an object that has been locked by the first process.
> This situation is a deadlock, and can involve more than two processes.
>
> Adaptive Server detects this situation, rolls back the transaction
> that has accumulated the least amount of CPU time, and notifies the
> application program of this action with Error 1205. This allows the
> other users' processes to move forward."
>
> We catch the DeadlockLoserDataAccessException in an ExceptionHandler
> and display a warning to user.
>
> Hope this helps.
>
> Pierre
>
> On Tue, 22 Feb 2005 13:12:23 +0100, Juergen Hoeller
> <ju...@in...> wrote:
> > 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
>

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

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

RE: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

I assume semantics like these, actually. But I guess it's quite hard to
discriminate these on the basis of SQL error codes, at least for some
databases.

I agree that it's probably best to throw CannotAcquireLockException for that
error code in SPR-733. There's always the option to customize, if someone
*really* needs more specific semantics.

Actually, if we play semantics gourmets here, shouldn't
DeadlockLoserDataAccessException be a subclass of
CannotAcquireLockException? After all, it's a lock that cannot be acquired
there, just for a specific reason...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Thomas Risberg
Sent: Sunday, March 20, 2005 5:46 PM
To: spr...@li...
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException


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

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
____________________________________________________

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

Well, I agree too. I'm mainly pointing out that we're currently not throwing
DeadlockLoserDataAccessException anywhere :-)

BTW, I still think DeadlockLoserDataAccessException should be a subclass of
CannotAcquireLockException. From the client's point of view, being a
deadlock loser is a special form of having been unable to acquire a lock. It
seems to me that, in most cases, a client cannot react more specifically to
a deadlock loser sitation than it can to having been unable to acquire a
lock.

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

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Monday, March 21, 2005 10:31 AM
To: spr...@li...
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException


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
____________________________________________________



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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

> 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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

Good point. Even if client code can't react specifically, we might want to
log it specifically to be able to track down deadlocks.

I guess the main problem is to track down the exact
DeadlockLoserDataAccessException error codes for each database. We need to
make sure that the error code actually always indicates a deadlock, rather
than just a "cannot acquire lock", even if the SQLException message says
something about a deadlock.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Monday, March 21, 2005 10:56 AM
To: spr...@li...
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException


> 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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

Juergen Hoeller wrote:
> Good point. Even if client code can't react specifically, we might want to
> log it specifically to be able to track down deadlocks.
> 
> I guess the main problem is to track down the exact
> DeadlockLoserDataAccessException error codes for each database. We need to
> make sure that the error code actually always indicates a deadlock, rather
> than just a "cannot acquire lock", even if the SQLException message says
> something about a deadlock.
Yes, we need to start an activity to get better error codes. Maybe we 
can offer users the chance of a free book or the like if they contribute 
a great set of exceptions for their chosen database :-) And of course, 
we need to review the categorization, as Thomas mentioned.

I keep meaning to go through Oracle error codes properly, myself, but 
have managed only to add about one or two codes per project...

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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

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]

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

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
>

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

I've prototypically added such an InvalidResultSetAccessException with
corresponding "invalidResultAccessCodes" on SQLErrorCodes, and added 17003
as such an error code for Oracle. Of course, we can still rework this if we
decide on some other solution.

Regarding DataAccessResourceFailureException: Indeed, resource failure can
happen during JDBC access too. But can we identify it through a SQL error
code? I think we can't: that error code usually comes from the database, and
the very point of DataAccessResourceFailureException is that we couldn't
access the database...

Juergen


-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Wednesday, March 23, 2005 2:56 PM
To: spr...@li...
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException


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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

Oracle must have that built into the driver:

Translating SQLException with SQLState 'null' and errorCode '17002' and message
[Io exception: Connection reset];

Thomas




Quoting Juergen Hoeller <ju...@in...>:

> I've prototypically added such an InvalidResultSetAccessException with
> corresponding "invalidResultAccessCodes" on SQLErrorCodes, and added 17003
> as such an error code for Oracle. Of course, we can still rework this if we
> decide on some other solution.
>
> Regarding DataAccessResourceFailureException: Indeed, resource failure can
> happen during JDBC access too. But can we identify it through a SQL error
> code? I think we can't: that error code usually comes from the database, and
> the very point of DataAccessResourceFailureException is that we couldn't
> access the database...
>
> Juergen
>
>
> -----Original Message-----
> From: Juergen Hoeller [mailto:ju...@in...]
> Sent: Wednesday, March 23, 2005 2:56 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer]
> DeadlockLoserDataAccessException vs CannotAcquireLockException
>
>
> 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
>
>
>
> -------------------------------------------------------
> 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
>

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

That's interesting... OK, so I guess I should add
"dataAccessResourceFailureCodes" again, and register 17002 there for Oracle.

Convinced :-)

Juergen



-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of tho...@tr...
Sent: Wednesday, March 23, 2005 4:22 PM
To: spr...@li...
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException



Oracle must have that built into the driver:

Translating SQLException with SQLState 'null' and errorCode '17002' and
message
[Io exception: Connection reset];

Thomas




Quoting Juergen Hoeller <ju...@in...>:

> I've prototypically added such an InvalidResultSetAccessException with
> corresponding "invalidResultAccessCodes" on SQLErrorCodes, and added 17003
> as such an error code for Oracle. Of course, we can still rework this if
we
> decide on some other solution.
>
> Regarding DataAccessResourceFailureException: Indeed, resource failure can
> happen during JDBC access too. But can we identify it through a SQL error
> code? I think we can't: that error code usually comes from the database,
and
> the very point of DataAccessResourceFailureException is that we couldn't
> access the database...
>
> Juergen
>
>
> -----Original Message-----
> From: Juergen Hoeller [mailto:ju...@in...]
> Sent: Wednesday, March 23, 2005 2:56 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer]
> DeadlockLoserDataAccessException vs CannotAcquireLockException
>
>
> 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
>
>
>
> -------------------------------------------------------
> 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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

That's fine - we should probably coordinate these changes with the exceptions
thrown by the new SqlRowSet - it currently throws
DataRetrievalFailureExeceptions when accessing row data like getString(3).

Thomas



Quoting Juergen Hoeller <ju...@in...>:

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

RE: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

[Juergen H. <ju...@in...>]

Yes, I guess I'll change the exceptions there to
InvalidResultSetAccessException  too. A subclass of
InvalidDataAccessResourceUsageException seems appropriate there.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of tho...@tr...
Sent: Wednesday, March 23, 2005 5:04 PM
To: spr...@li...
Subject: Re: [Springframework-developer]
DeadlockLoserDataAccessException vs CannotAcquireLockException



That's fine - we should probably coordinate these changes with the
exceptions
thrown by the new SqlRowSet - it currently throws
DataRetrievalFailureExeceptions when accessing row data like getString(3).

Thomas



Quoting Juergen Hoeller <ju...@in...>:

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

Re: [Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

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