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