ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Maves" <nathan.ma...@gmail.com>
Subject Re: Retry Logic
Date Thu, 31 Aug 2006 16:01:15 GMT
I was just going to suggest that.  We here use Oracle and this option
automaticlly set.

If the process does reach this timeout you will get an exception.  But
in this case there is most likely something more serious wrong.

Nathan

On 8/30/06, Brad Balmer <bbalmer@peapod.com> wrote:
> 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