transactions.po

hibernate-distribution-3.3.1.GA-dist.zip源码

msgid ""
"The session-per-request pattern is not the only useful concept you can use "
"to design units of work. Many business processes require a whole series of "
"interactions with the user interleaved with database accesses. In web and "
"enterprise applications it is not acceptable for a database transaction to "
"span a user interaction. Consider the following example:"
msgstr ""
"session-per-request模式不仅仅是一个可以用来设计操作单元的有用概念。很多业务处"
"理都需 要一系列完整的与用户之间的交互，而这些用户是指对数据库有交叉访问的用"
"户。在基于web的应用和企业 应用中，跨用户交互的数据库事务是无法接受的。考虑下"
"面的例子："

#. Tag: para
#: transactions.xml:171
#, no-c-format
msgid ""
"The first screen of a dialog opens, the data seen by the user has been "
"loaded in a particular <literal>Session</literal> and database transaction. "
"The user is free to modify the objects."
msgstr ""
"在界面的第一屏，打开对话框，用户所看到的数据是被一个特定的 <literal>Session</"
"literal> 和数据 库事务载入(load)的。用户可以随意修改对话框中的数据对象。"

#. Tag: para
#: transactions.xml:178
#, no-c-format
msgid ""
"The user clicks \"Save\" after 5 minutes and expects his modifications to be "
"made persistent; he also expects that he was the only person editing this "
"information and that no conflicting modification can occur."
msgstr ""
"5分钟后，用户点击“保存”，期望所做出的修改被持久化；同时他也期望自己是唯一修改"
"这个信息的人，不会出现 修改冲突。"

#. Tag: para
#: transactions.xml:186
#, no-c-format
msgid ""
"We call this unit of work, from the point of view of the user, a long "
"running <emphasis>conversation</emphasis> (or <emphasis>application "
"transaction</emphasis>). There are many ways how you can implement this in "
"your application."
msgstr ""
"从用户的角度来看，我们把这个操作单元称为长时间运行的<emphasis>对话</emphasis>"
"（conversation）,或者(or <emphasis>应用事务</emphasis>,application "
"transaction)。 在你的应用程序中，可以有很多种方法来实现它。"

#. Tag: para
#: transactions.xml:192
#, no-c-format
msgid ""
"A first naive implementation might keep the <literal>Session</literal> and "
"database transaction open during user think time, with locks held in the "
"database to prevent concurrent modification, and to guarantee isolation and "
"atomicity. This is of course an anti-pattern, since lock contention would "
"not allow the application to scale with the number of concurrent users."
msgstr ""
"头一个幼稚的做法是，在用户思考的过程中，保持<literal>Session</literal>和数据"
"库事务是打开的， 保持数据库锁定，以阻止并发修改，从而保证数据库事务隔离级别和"
"原子操作。这种方式当然是一个反模式， 因为锁争用会导致应用程序无法扩展并发用户"
"的数目。"

#. Tag: para
#: transactions.xml:200
#, fuzzy, no-c-format
msgid ""
"Clearly, we have to use several database transactions to implement the "
"conversation. In this case, maintaining isolation of business processes "
"becomes the partial responsibility of the application tier. A single "
"conversation usually spans several database transactions. It will be atomic "
"if only one of these database transactions (the last one) stores the updated "
"data, all others simply read data (e.g. in a wizard-style dialog spanning "
"several request/response cycles). This is easier to implement than it might "
"sound, especially if you use Hibernate's features:"
msgstr ""
"很明显，我们必须使用多个数据库事务来实现这个对话。在这个例子中，维护业务处理"
"的 事务隔离变成了应用程序层的部分责任。一个对话通常跨越多个数据库事务。如果仅"
"仅只有一 个数据库事务（最后的那个事务）保存更新过的数据，而所有其他事务只是单"
"纯的读取数据（例如在一 个跨越多个请求/响应周期的向导风格的对话框中），那么应"
"用程序事务将保证其原子性。这种方式比听 起来还要容易实现，特别是当你使用了"
"Hibernate的下述特性的时候："

#. Tag: para
#: transactions.xml:213
#, fuzzy, no-c-format
msgid ""
"<emphasis>Automatic Versioning</emphasis> - Hibernate can do automatic "
"optimistic concurrency control for you, it can automatically detect if a "
"concurrent modification occurred during user think time. Usually we only "
"check at the end of the conversation."
msgstr ""
"<emphasis>自动版本化</emphasis> - Hibernate能够自动进行乐观并发控制 ，如果在"
"用户思考 的过程中发生并发修改，Hibernate能够自动检测到。一般我们只在对话结束"
"时才检查。"

#. Tag: para
#: transactions.xml:221
#, no-c-format
msgid ""
"<emphasis>Detached Objects</emphasis> - If you decide to use the already "
"discussed <emphasis>session-per-request</emphasis> pattern, all loaded "
"instances will be in detached state during user think time. Hibernate allows "
"you to reattach the objects and persist the modifications, the pattern is "
"called <emphasis>session-per-request-with-detached-objects</emphasis>. "
"Automatic versioning is used to isolate concurrent modifications."
msgstr ""
"<emphasis>脱管对象</emphasis>（Detached Objects）- 如果你决定采用前面已经讨论"
"过的 <emphasis>session-per-request</emphasis>模式，所有载入的实例在用户思考的"
"过程 中都处于与Session脱离的状态。Hibernate允许你把与Session脱离的对象重新关"
"联到Session 上，并且对修改进行持久化，这种模式被称为 <emphasis>session-per-"
"request-with-detached-objects</emphasis>。自动版本化被用来隔离并发修改。"

#. Tag: para
#: transactions.xml:231
#, fuzzy, no-c-format
msgid ""
"<emphasis>Extended (or Long) Session</emphasis> - The Hibernate "
"<literal>Session</literal> may be disconnected from the underlying JDBC "
"connection after the database transaction has been committed, and "
"reconnected when a new client request occurs. This pattern is known as "
"<emphasis>session-per-conversation</emphasis> and makes even reattachment "
"unnecessary. Automatic versioning is used to isolate concurrent "
"modifications and the <literal>Session</literal> is usually not allowed to "
"be flushed automatically, but explicitly."
msgstr ""
"<emphasis>Extended (or Long) Session</emphasis> - Hibernate 的"
"<literal>Session</literal> 可以在数据库事务提交之后和底层的JDBC连接断开，当一"
"个新的客户端请求到来的时候，它又重新连接上底层的 JDBC连接。这种模式被称之为"
"<emphasis>session-per-conversation</emphasis>，这种情况可 能会造成不必要的"
"Session和JDBC连接的重新关联。自动版本化被用来隔离并发修改, <literal>Session</"
"literal>通常不允许自动flush,而是明确flush。"

#. Tag: para
#: transactions.xml:244
#, no-c-format
msgid ""
"Both <emphasis>session-per-request-with-detached-objects</emphasis> and "
"<emphasis>session-per-conversation</emphasis> have advantages and "
"disadvantages, we discuss them later in this chapter in the context of "
"optimistic concurrency control."
msgstr ""
"<emphasis>session-per-request-with-detached-objects</emphasis> 和 "
"<emphasis>session-per-conversation</emphasis> 各有优缺点，我们在本章后面乐观"
"并发 控制那部分再进行讨论。"

#. Tag: title
#: transactions.xml:253
#, no-c-format
msgid "Considering object identity"
msgstr "关注对象标识(Considering object identity)"

#. Tag: para
#: transactions.xml:255
#, no-c-format
msgid ""
"An application may concurrently access the same persistent state in two "
"different <literal>Session</literal>s. However, an instance of a persistent "
"class is never shared between two <literal>Session</literal> instances. "
"Hence there are two different notions of identity:"
msgstr ""
"应用程序可能在两个不同的<literal>Session</literal>中并发访问同一持久化状态，"
"但是， 一个持久化类的实例无法在两个 <literal>Session</literal>中共享。因此有"
"两种不同的标识语义："

#. Tag: term
#: transactions.xml:264
#, no-c-format
msgid "Database Identity"
msgstr "数据库标识"

#. Tag: literal
#: transactions.xml:267
#, no-c-format
msgid "foo.getId().equals( bar.getId() )"
msgstr "foo.getId().equals( bar.getId() )"

#. Tag: term
#: transactions.xml:272
#, no-c-format
msgid "JVM Identity"
msgstr "JVM 标识"

#. Tag: literal
#: transactions.xml:275
#, no-c-format
msgid "foo==bar"
msgstr "foo==bar"

#. Tag: para
#: transactions.xml:281
#, fuzzy, no-c-format
msgid ""
"Then for objects attached to a <emphasis>particular</emphasis> "
"<literal>Session</literal> (i.e. in the scope of a <literal>Session</"
"literal>) the two notions are equivalent, and JVM identity for database "
"identity is guaranteed by Hibernate. However, while the application might "
"concurrently access the \"same\" (persistent identity) business object in "
"two different sessions, the two instances will actually be \"different"
"\" (JVM identity). Conflicts are resolved using (automatic versioning) at "
"flush/commit time, using an optimistic approach."
msgstr ""
"对于那些关联到 <emphasis>特定</emphasis><literal>Session</literal> （也就是在"
"单个<literal>Session</literal>的范围内）上的对象来说，这 两种标识的语义是等价"
"的，与数据库标识对应的JVM标识是由Hibernate来保 证的。不过，当应用程序在两个不"
"同的session中并发访问具有同一持久化标 识的业务对象实例的时候，这个业务对象的"
"两个实例事实上是不相同的（从 JVM识别来看）。这种冲突可以通过在同步和提交的时"
"候使用自动版本化和乐 观锁定方法来解决。"

#. Tag: para
#: transactions.xml:290
#, no-c-format
msgid ""
"This approach leaves Hibernate and the database to worry about concurrency; "
"it also provides the best scalability, since guaranteeing identity in single-"
"threaded units of work only doesn't need expensive locking or other means of "
"synchronization. The application never needs to synchronize on any business "
"object, as long as it sticks to a single thread per <literal>Session</"
"literal>. Within a <literal>Session</literal> the application may safely use "
"<literal>==</literal> to compare objects."
msgstr ""
"这种方式把关于并发的头疼问题留给了Hibernate和数据库；由于在单个线程内，操作单"
"元中的对象识别不 需要代价昂贵的锁定或其他意义上的同步，因此它同时可以提供最好"
"的可伸缩性。只要在单个线程只持有一个 <literal>Session</literal>，应用程序就不"
"需要同步任何业务对象。在<literal>Session</literal> 的范围内，应用程序可以放心"
"的使用<literal>==</literal>进行对象比较。"

#. Tag: para
#: transactions.xml:299
#, no-c-format
msgid ""
"However, an application that uses <literal>==</literal> outside of a "
"<literal>Session</literal>, might see unexpected results. This might occur "
"even in some unexpected places, for example, if you put two detached "
"instances into the same <literal>Set</literal>. Both might have the same "
"database identity (i.e. they represent the same row), but JVM identity is by "
"definition not guaranteed for instances in detached state. The developer has "
"to override the <literal>equals()</literal> and <literal>hashCode()</"
"literal> methods in persistent classes and implement his own notion of "
"object equality. There is one caveat: Never use the database identifier to "
"implement equality, use a business key, a combination of unique, usually "
"immutable, attributes. The database identifier will change if a transient "
"object is made persistent. If the transient instance (usually together with "
"detached instances) is held in a <literal>Set</literal>, changing the "
"hashcode breaks the contract of the <literal>Set</literal>. Attributes for "
"business keys don't have to be as stable as database primary keys, you only "
"have to guarantee stability as long as the objects are in the same "
"<literal>Set</literal>. See the Hibernate website for a more thorough "
"discussion of this issue. Also note that this is not a Hibernate issue, but "
"simply how Java object identity and equality has to be implemented."
msgstr ""
"不过，应用程序在<literal>Session</literal>的外面使用<literal>==</literal>进行"
"对象比较可能会 导致无法预期的结果。在一些无法预料的场合，例如，如果你把两个脱"
"管对象实例放进同一个 <literal>Set</literal>的时候，就可能发生。这两个对象实例"
"可能有同一个数据库标识（也就是说， 他们代表了表的同一行数据），从JVM标识的定"
"义上来说，对脱管的对象而言，Hibernate无法保证他们 的的JVM标识一致。开发人员必"
"须覆盖持久化类的<literal>equals()</literal>方法和 <literal>hashCode()</"
"literal> 方法，从而实现自定义的对象相等语义。警告：不要使用数据库标识 来实现"
"对象相等，应该使用业务键值，由唯一的，通常不变的属性组成。当一个瞬时对象被持"
"久化的时 候，它的数据库标识会发生改变。如果一个瞬时对象（通常也包括脱管对象实"
"例）被放入一 个<literal>Set</literal>，改变它的hashcode会导致与这个"
"<literal>Set</literal>的关系中断。虽 然业务键值的属性不象数据库主键那样稳定不"
"变，但是你只需要保证在同一个<literal>Set</literal> 中的对象属性的稳定性就足够"
"了。请到Hibernate网站去寻求这个问题更多的详细的讨论。请注意，这不是一 个有关"
"Hibernate的问题，而仅仅是一个关于Java对象标识和判等行为如何实现的问题。"

#. Tag: title
#: transactions.xml:320
#, no-c-format
msgid "Common issues"
msgstr "常见问题"