ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Balmer <bbal...@peapod.com>
Subject Re: Retry Logic
Date Wed, 30 Aug 2006 18:10:35 GMT
What I'm going to do for now is use the database itself to do this.  We 
are using Informix so I'm making sure that each connection coming from 
the pool has a LOCK MODE WAIT set to X seconds.  Thus, there will be an 
implicit retry if there is a lock until X seconds has ended (all 
occurring on the db server).

This seems the easiest way since I don't want to change the code (or as 
little as possible) to do this.  I'm sure that because of the different 
sql error codes between different db vendors there isn't one global way 
of doing it, but I was hoping that I could give a list of codes that 
could be trapped for and retried if found.  Maybe this is just another 
layer in my applications that I need to add (in the future) between 
Spring and iBatis.

Thanks for your input.

Chris Lamey wrote:
> This is very custom behavior and not something I've seen as an out of
> the box feature in iBATIS (or Hiberante, for that matter), but I don't
> know the iBATIS codebase well enough to say if it's easy to add.  My
> guess would be that it is not easy and that's why nobody's jumped in on
> this thread.
>
> It sounds like your app is using table/row locks with some kind of
> NOWAIT.  Could you configure things so that rather than throwing the
> "Can't get a lock" exception, the second statement merely waits for the
> lock to be released?  That's just an idea, it might not be feasible for
> a variety of reasons.
>
> Cheers,
> Chris
>
> On Wed, 2006-08-30 at 11:13 -0500, Brad Balmer wrote:
>   
>> A table or row is locked by a person or a process.  Another 
>> person/process wants to update the row.
>>
>> The update statement is sent to the db but since the row is locked the 
>> update fails and throws a SQLException.  I would like to catch this 
>> exception and if it is due to a lock, wait for x number of seconds and 
>> retry the update.
>>
>> Once the first person has completed their update, the row is unlocked 
>> and the second person's update, which initially failed, will succeed.
>>
>> This can easily be done programatically, but I don't want to have to 
>> change the code in 50-60 locations per application where an 
>> insert/update/delete occurs.
>>
>> I was wondering if something like this was built into iBatis (or by 
>> extending a class I could do it).
>>
>>
>>
>> Chris Lamey wrote:
>>     
>>> Could you please provide more detail about what you're trying to do?  Is
>>> this retry on exception or some kind of data condition?  Is this when
>>> one record in a batch fails and you want to keep going?  What would
>>> change that would cause a retry to succeed?
>>>
>>> On Wed, 2006-08-30 at 09:20 -0500, Brad Balmer wrote:
>>>   
>>>       
>>>> Is there any built-in retry logic for inserts/updates? 
>>>>
>>>> If not, does anybody have any ideas of the best way to implement this in

>>>> a system that is already built and up and running?
>>>>
>>>> We are using Spring with iBatis.
>>>>
>>>> Thanks
>>>>
>>>> ___________________________
>>>> Brad Balmer
>>>> Application Architect
>>>> Peapod, Inc.
>>>> 847-583-6306
>>>>
>>>> This email may contain confidential or legally privileged information that
is intended only for the individual or entity named as the recipient. If you are not the intended
recipient, you are hereby notified that any disclosure, copying, distribution, or reliance
upon the contents of this email is strictly prohibited. If you have received this email in
error, please contact the sender so that proper delivery can be arranged, and then please
delete this message. Thank you.
>>>>
>>>>
>>>>     
>>>>         

-- 

___________________________
Brad Balmer
Application Architect
Peapod, Inc.
847-583-6306

This email may contain confidential or legally privileged information that is intended only
for the individual or entity named as the recipient. If you are not the intended recipient,
you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents
of this email is strictly prohibited. If you have received this email in error, please contact
the sender so that proper delivery can be arranged, and then please delete this message. Thank
you.



Mime
View raw message