单例 REST 数据库资源是个好主意吗？
这是我的情况。我有一个名为 SomethingDao 的类，其中包含查询表的所有逻辑。
然后，我还有somethingDaoResource，它是一个Jersey API 资源，也是一个Singleton，并且通过Spring 实例化一个somethingDao 对象（即，我将一个数据源注入到somethingDao 中）。
然后，我有一个 Jersey API BusinessLogicResource，它执行以下操作：
somethingDaoResource.getInstance().getsomethingDao()，它获取 someDao 对象，然后我在该对象上触发多个查询。
我的问题是，这算是一个好的设计吗？我主要担心的是，每次有人向我的businessLogicResource发送HTTP请求时，如果somethingDaoResource不是单例（或静态？），那么就会创建somethingDao的新实例，并打开一个新连接，这需要一个一会儿要做。
任何建议都非常受欢迎。
PS - 我还有一个 c3p0 连接池。
Here's my situation. I have a class called somethingDao that contains all my logic for querying a table.
Then, I also have somethingDaoResource, which is a Jersey API resource, but also a Singleton, and is instantiating a somethingDao object via Spring (i.e., I'm injecting a datasource into somethingDao).
Then, I have a Jersey API businessLogicResource that does:
somethingDaoResource.getInstance().getsomethingDao() which gets me the somethingDao object at which I then fire multiple queries.
My question is, is this considered a good design? My main concern is that every time someone sends a HTTP request to my businessLogicResource, if the somethingDaoResource wasn't a Singleton (or a static?), then that would create a new instance of somethingDao, and open a new connection, which takes a while to do.
Any suggestions are more than welcome.
PS - I also have a c3p0 connection pool.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
最常见的做法是将 DAO 对象作为无状态单例。他们不会打开和关闭连接，而是从池中借用一个连接，然后在完成后归还。您可以限制池中的最大连接数。
在 Web 应用程序中拥有有状态和单例的东西通常是一个坏主意。它可能会导致各种读/写冲突或线程锁定。这种方法还消除了将应用程序分布在多个服务器上的任何可能性，这打破了 REST 架构限制之一。
The most common practice is to have DAO objects as stateless singletons. Instead of opening and closing a connection they would borrow one from a pool and then return it when done. You can limit the maximum number of connections in the pool.
Having something statefull and a singleton in a web application is usually a bad idea. It might cause all kinds of read/write conflicts or thread locking. This approach also kills any possibility of distributing your application over a number of servers, which breaks one of the REST architectural constraints.