users@glassfish.java.net
Re: How does an explicit EntityManager.lock() call prevent dirty reads in JPA
This message
: [
Message body
] [ More options (
top
,
bottom
) ]
Related messages
: [
Next message
] [
Previous message
] [
In reply to
] [
Next in thread
] [
Replies
]
Contemporary messages sorted
: [
by date
] [
by thread
] [
by subject
] [
by author
] [
by messages with attachments
]
From
: <
glassfish_at_javadesktop.org
>
Date
: Mon, 10 Nov 2008 10:38:45 PST
http://en.wikipedia.org/wiki/Isolation_(database_systems
)#READ_COMMITTED
The database would prevent T2 from seeing T1's changes until T1 commits, hence there is no dirty read to begin with. All modifications take place atomically at commit time, not before.
[Message sent by forum member 'cowwoc' (cowwoc)]
http://forums.java.net/jive/thread.jspa?messageID=315858
This message
: [
Message body
]
Next message
:
glassfish_at_javadesktop.org: "Re: How does an explicit EntityManager.lock() call prevent dirty reads in JPA"
Previous message
:
Dick Davies: "Re: session replication checklist ? or monitoring tips?"
In reply to
:
glassfish_at_javadesktop.org: "Re: How does an explicit EntityManager.lock() call prevent dirty reads in JPA"
Next in thread
:
glassfish_at_javadesktop.org: "Re: How does an explicit EntityManager.lock() call prevent dirty reads in JPA"
Reply
:
glassfish_at_javadesktop.org: "Re: How does an explicit EntityManager.lock() call prevent dirty reads in JPA"
Contemporary messages sorted
: [
by date
] [
by thread
] [
by subject
] [
by author
] [
by messages with attachments
]