openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <michael.d.d...@gmail.com>
Subject Re: MySQL bug 50174 and OpenJPA ant task.
Date Wed, 10 Nov 2010 14:55:50 GMT
I don't think we have a lot of good options. We can post on the MySQL bug
report but I'm not going to hold my breath.

Sorry, I'm not seeing a great solution. I suppose a retry-capable version of
the ant task would work, but might be easier said than done.

For general runtime, I wouldn't be opposed to adding a new exception type
that indicates the transaction is likely to succeed if you retry. It might
have to be a linked exception within the PersistenceException, but it would
be more friendly than littering your app code with database specific
exceptions (or SQLStates).

-mike

On Tue, Nov 9, 2010 at 10:22 AM, Jean-Baptiste BRIAUD -- Novlog <
j-b.briaud@novlog.com> wrote:

> Hi Mike,
>
> In fact, I'm just wondering what should be the best option ... but all look
> like bad :-)
> It is not OpenJPa's role to manage MySQL specific bug but it is not
> possible for OpenJPA's user to simply catch that MySQL exception.
> Also, a more generic way for automatic retry would be ugly. It is better
> for a developer to solve the problem rather than doing it again in the hope
> the error will not happen twice ;-)
> So, I'm puzzled.
>
> The most difficult zone is for the OpenJPA tooling Ant tasks : no simple
> way to try/catch that bloody MySQL exception.
> The only thing I can think about is one custom Ant task per OpenJPa ant
> task used that would catch that exception, this is painful.
>
> Could we say, with all the weight of this OpenJPA group,  to MySQL to
> increase priority or gravity on that bug ?
> I'm really astonished that such a failure is tagged as not so important ...
>
> What do you think ?
>
> On 9 nov. 2010, at 16:58, Michael Dick wrote:
>
> > I think there needs to be some level of application work to resolve the
> > problem. OpenJPA could be updated to catch the MySQL specific exception
> and
> > issue a more generic retry exception to the application. I'm not sure we
> > want to add automatic retry logic to every interaction with the database
> to
> > cover a particularly annoying MySQL bug.
> >
> > Is that in line with what you were thinking, or did I mis something along
> > the way?
> >
> > -mike
> >
> > On Tue, Nov 9, 2010 at 2:16 AM, Jean-Baptiste BRIAUD -- Novlog <
> > j-b.briaud@novlog.com> wrote:
> >
> >> Yes.
> >>
> >> On 8 nov. 2010, at 21:51, Rick Curtis wrote:
> >>
> >>> do you have connection pooling configured?
> >>>
> >>> Thanks,
> >>> Rick
> >>>
> >>> On Mon, Nov 8, 2010 at 2:21 PM, Jean-Baptiste BRIAUD -- Novlog <
> >>> j-b.briaud@novlog.com> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> http://bugs.mysql.com/bug.php?id=50174
> >>>>
> >>>> This MySQL bug is quite annoying :
> >>>> Under certain CPU load level (witch is unknown) under *nix (any unix
> >>>> apparently), the connection to the DB failed.
> >>>> This bug is tagged by MySQL as low priority because there is a
> >> workaround.
> >>>> The only workaround is to try again was was done during that specific
> >>>> communication error.
> >>>>
> >>>> This might be fine when dealing directly with the database, even with
> >>>> OpenJPA code, because we can try/catch that specific exception and
> retry
> >>>> (com.mysql.jdbc.exceptions.jdbc4.CommunicationsException).
> >>>>
> >>>> The problem I have is when I'm using some OpenJPA ant task like
> >>>> org.apache.openjpa.jdbc.meta.MappingTool.
> >>>> I can't try/catch.
> >>>>
> >>>> The more general problem I have is that my code will become full of
> that
> >>>> MySQL specific error while I'm using OpenJPA not to have any database
> >>>> specific code...
> >>>>
> >>>> Should I wrap that ant task in a custom one where I would try/catch
?
> >>>> Should we take care of that MySQL specific bug in OpenJPA so we still
> >>>> "encapsulate" MySQL for OpenJPA users ?
> >>>> Did we encountered that kind of situation before ?
> >>>>
> >>>> I found the hard way that it was a MySQL known bug, I also hope that
> >> email
> >>>> may help others to save time :-)
> >>>>
> >>>> JBB.
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message