EJB3 DataSource DataSource.getConnection [英] EJB3 DataSource DataSource.getConnection
问题描述
在CMT J2EE环境（容器管理事务）中，当JDNI查找DataSource对象并调用 DataSource.getConnection ？时，使用什么事务/连接>
这个连接是（潜在分布式）事务的一部分吗？每次为同一个DataSource对象调用它时， getConnection（）返回同一个Connection吗？我只知道使用本地SQL语句通过相同的EntityManager使用连接。
这是让我困惑的东西。据我所知，SessionContext定义了一个事务系统，每次使用数据源时都使用它。我有一个问题，在会话bean中使用 DataSource.getConnection（），然后关闭这个连接。如果遇到问题，则会发出 SessionContext.setForRollBack（true）。
服务与DataSource相关？
如果我们每次使用或至少查找一个数据源时产生一个新的连接，我有一些问题要了解我已经知道的东西。任何澄清将是美好的。我知道容器管理的事务和其他系统，但是DataSource的实际行为完全在我之外。
是不是数据库专有的概念，例如JMS连接会话也可以是容器管理事务的一部分。想法是如果一个或多个方法在容器管理的事务边界下运行，容器将根据需要提交或回滚事务。
在数据库相关数据源，有多个层，fist是由容器维护的管理池连接，第二是数据库驱动程序与数据库的实际连接管理，在Java中一个Connection是一个与数据库的会话的抽象而不是一个
在上述情况下，您的问题可以通过以下方式解决：
当JDNI查找DataSource对象并调用DataSource.getConnection时，使用什么事务/连接。
在容器管理事务下，虽然它是依赖于实现的，但是与数据库的连接/会话是相关联的，并用事务边界标记。实际的物理连接可以由驱动程序与数据库共享，但对应用程序和容器都是透明的。
部分（潜在分布式）事务？每次我为同一个DataSource对象调用它时，getConnection是否返回相同的连接？
底层套接字到驱动程序打开的数据库。它在逻辑上是一个单独的会话，如果在事务边界内，相同的会话与从数据源检索的连接相关联，那么这是如何实现的是容器设计的一部分
我有一个问题，在会话bean中使用DataSource.getConnection，然后关闭此连接。
在连接的池化实现中，Connection.close（）没有影响，连接返回到池（ http://commons.apache.org/proper/commons-dbcp/api-1.3/org/apache/commons/dbcp/PoolableConnection.html ），此行为对于所有池都相似。因此，连接不一定与容器事务边界分离，尽管连接不应该在容器管理事务中关闭。同样，commit，setAutoCommit，rollback不能在CMT内调用，因为这将发出与实际数据库相当的以下命令，并且事务的行为将在此之后被定义。
In a CMT J2EE environement (Container Managed Transaction) what transaction / connection is used when I JDNI-lookup for a DataSource object and invoke DataSource.getConnection?
Is this connection part of the (potentially distributed) transaction? Does getConnection() return the same Connection every time I call it for the same DataSource object? I only know using Connections by the same EntityManager using native SQL statements.
It is something that keeps me puzzling. As I understood the SessionContext defines a transactional system that is used throught every time I use a datasource. I have the problem that inside a session bean a DataSource.getConnection() is used and this connection is then closed. If a problem is encountered SessionContext.setForRollBack(true) is issued.
Therefore how does the transactional context of a service relate to a DataSource?
If we spawn a new Connection each time a datasource is used or at least looked up, I have problems to understand things I already know. Any clarification would be wonderful. I know container managed transaction and other systems, but the actual behavior of DataSource is totally beyond me.
In Java EE a transaction is a concept that is not exclusive to databases, for example JMS connection sessions can also be part of container managed transaction. The idea is if one or more than one method is running under container managed transaction boundary, the container will commit or rollback the transaction as needed.
In data base related data source, there are multiple layers, fist is the managed pool of connection which is maintained by the container, second is the actual connection management of the database driver with the database, in Java a Connection is an abstraction for a session with a database and not a physical connection, that is managed by the driver.
With the above context, your questions could be addressed viz.:
what transaction / connection is used when I JDNI-lookup for a DataSource object and invoke DataSource.getConnection.
Under container managed transaction, though it is implementation dependent, a connection/session with the database is associated that is marked with the transaction boundary. The actual physical connection could be shared with the database by the driver but that is transparent to application as well as the container.
Is this connection part of the (potentially distributed) transaction? Does getConnection return the same Connection every time I call it for the same DataSource object?
Refer above, a Connection has no relation with the underlying socket to the database as opened by the driver. It is logically a separate session and if within transaction boundary, the same session is associated with the connection retrieved from the data source, how this is implemented is part of the container design
I have the problem that inside a session bean a DataSource.getConnection is used and this connection is then closed
In a pooled implementation for connection a Connection.close() has no impact, the connection is returned to the pool(http://commons.apache.org/proper/commons-dbcp/api-1.3/org/apache/commons/dbcp/PoolableConnection.html), this behaviour is similar for all pools. So clsing a connection does not necessarily disassociate it from container transaction boundary, though a connection should not be closed within container managed transaction. Similarly, commit, setAutoCommit, rollback must not be called from within CMT as this will issue the following command equivalent to the actual database and the behaviour of the transaction after that will undefined.
这篇关于EJB3 DataSource DataSource.getConnection的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
