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 < [email protected]> 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 < > > [email protected]> 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 < > >>> [email protected]> 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. > >> > >> > >
