Wicket：在哪里处理 JDBC 连接错误

发布于 2024-09-09 04:18:20 字数 3385 浏览 5 评论 0原文

我有一个基于 Spring 的 Wicket 应用程序。
有一个池化数据源 bean。
现在，当 MySQL 死机时，我会得到一个带有堆栈跟踪的默认 Wicket 错误页面。

我想处理这种情况，并只允许某些页面完全显示（静态页面），并为其他页面显示自定义错误页面。

我应该如何有效地实施这一点？

我知道我可以捕获页面代码中的异常，但这是一种不可靠的 MySQL 实例，并且经常出现故障:) 或者，考虑其他类型的不可靠资源。为每个页面添加一个 if 似乎效率很低。我想要一些需要资源的页面列表，并将对其的请求重定向到自定义错误页面。

我正在考虑使用一些全局布尔 isResourceReady 和一些线程，该线程将在该错误时启动并定期检查可用性，并最终在资源返回时允许动态页面。

感谢您的提示。

Root cause:

java.net.ConnectException: Connection refused
at ... java.net stuff
... JDBC stuff
... Spring stuff
... DBCP and Pool stuff
... Hibernate stuff
at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:88)
at cz.oz.wicket.stack.dao.TestEntityDaoImpl$1.doInJpa(TestEntityDaoImpl.java:36)
at org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:184)
at cz.oz.wicket.stack.dao.TestEntityDaoImpl.createSyntheticTestEntity(TestEntityDaoImpl.java:32)
at cz.oz.wicket.stack.pages.home.HomePage.<init>(HomePage.java:31)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:188)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:65)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:298)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:320)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234)
at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mo

原文

I have a Spring based Wicket app.
There's a pooled datasource bean.
Now, when MySQL is dead, I get a default Wicket error page with a stacktrace.

I'd like to handle this situation and to only allow some pages to fully display (the static ones), and to show a custom error page for the others.

How should I efficiently implement this?

I know I could catch exceptions in the page's code, but this is kind of unreliable MySQL instance and it's down quite often :) Or, think of other kind of unreliable resource.
Putting an if for each page seems inefficient. I'd like some list of pages that need the resource, and redirecting requests to it to a custom error page.

I was thinking about having some global boolean isResourceReady, and some thread which would start upon that error and periodically check for availability, and eventually allow the dynamic pages when the resource is back.

Thanks for tips.

Root cause:

java.net.ConnectException: Connection refused
at ... java.net stuff
... JDBC stuff
... Spring stuff
... DBCP and Pool stuff
... Hibernate stuff
at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:88)
at cz.oz.wicket.stack.dao.TestEntityDaoImpl$1.doInJpa(TestEntityDaoImpl.java:36)
at org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:184)
at cz.oz.wicket.stack.dao.TestEntityDaoImpl.createSyntheticTestEntity(TestEntityDaoImpl.java:32)
at cz.oz.wicket.stack.pages.home.HomePage.<init>(HomePage.java:31)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:188)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:65)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:298)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:320)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234)
at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mo

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

澉约 2024-09-16 04:18:20

您可能最好使用 Wicket 中的正常错误页面处理< /a>.

但如果您想预测异常而不是对其做出反应，这似乎是 ServletFilter 的自然应用。特别是如果您已经在使用 spring OpenSessionInViewFilter，您可以将其子类化并覆盖

protected Session getSession(SessionFactory sessionFactory)

以检测您没有数据库连接并转发到特殊页面。

如果您通过过滤器执行此操作，则是否转到错误页面的决定可能仍然必须由某种全局驱动，但这可能只是您在您的静态页面中维护的列表。 WebApplication 对象，它已经是单例了。

You might be best off using the normal error page handling in Wicket.

But if you want to anticipate the exception instead of reacting to it, this seems like a natural application of a ServletFilter. Particularly if you're already using the spring OpenSessionInViewFilter, you might subclass that and override the

protected Session getSession(SessionFactory sessionFactory)

to detect that you've got no database connection and forward to a special page.

If you're doing it by a filter, the decision of whether to go to the error page or not might still have to be driven by some sort of global, but this might just be a list of your static pages that you maintain in your WebApplication object, which is already a singleton.

回复收藏 0 原文