Home » Eclipse Projects » EclipseLink » JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink
| JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376345] |
Mon, 14 July 2008 20:56  |
Eclipse User |
|
|
|
Originally posted by: luxspes.yahoo.com
Hi!
I want to see if I can use EclipseLink with JBoss Seam, but, to make
optimal use of JBossSeam, I want to take advantage of atomic transactions
managed in the context of a Seam conversation... the problem is that, to
do that, I need to find out what is the equivalent of Hibernate's
FlushModeType.MANUAL.
What is FlushModeType.MANUAL? Well as you may know, the JPA standard only
supports 2 FlushModeTypes: FlushModeType.COMMIT that flushes object
changes to the database on transaction commit, and FlushModeType.AUTO,
that flushes object changes whenever it is necessary to run a query (In
the case of TopLink I guess FlushModeType.AUTO helps to avoid the need to
use Conforming Queries).
But what if I want to stop all flushing to the database until I say so?
Well, for that Hibernate has FlushModeType.MANUAL, the funny thing is that
AFAIK Hibernate has no support for Conforming Queries or In-Memory
Queries, and therefore EclipseLink and its Conforming Queries may be a
better solution for this kind of use cases...
But I am new to EclipseLink/TopLink and I can not find anything in the
documentation on how to enable something like FlushModeType.MANUAL with
some EclipseLink propietary extension...
Is there a way to do it?
Regards,
|
|
| | | | | |
| Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376362 is a reply to message #376360] |
Thu, 17 July 2008 08:34  |
| Eclipse User |
|
|
|
Originally posted by: luxspes.yahoo.com
But, how do you warrant transaction consistency (repeatable reads and
stuff like that) without a transaction on each request response cycle?)
Or are you suggesting to keep one transaction open for each conversation?
(A conversation can last a lot of time, serveral minutes, wouldn't that
hurt database performance?)
Sebastien Tardif wrote that "Repeatable read/isolation are provided by the
unit of work." is that a feature of EclipseLink?" how does it achive it
without keeping an open connection to the database? For example, if I ask
for the all the records in a table twice inside a particular
requeste/response cycle, and between those calls another user inserted a
new record... how does it know that it should ignore it? and... does it
work to for scalar queries (select count, select sum)?
Or should we deal with this using "begin transaction/rollback" (instead
of, as Seam does it "begin transaction/commit") can I begin a transaction
and then rollback it to warrant transaction consistency between several
queries and then, since it was only for reading, rollback it at the end of
the request response cycle without adverse secondary effects on the
objects EntityManager? (or the EntityManager must be discarded if the
transaction is rollbacked?)
Thanks
Regards,
|
|
|
| Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376885 is a reply to message #376362] |
Tue, 22 July 2008 14:21 |
| Eclipse User |
|
|
|
There are a couple of points that I think should be brought out, here.
The first is that the reason why FlushMode.MANUAL is not in the JPA spec
is that it violates the rules of transactions to have a mode where a
transaction is committed but the changes are not actually persisted. This
can cause a whole host of problems that become obvious with a trivial
amount of think time. The problem is really that Seam is wanting to have a
conversational transaction (sometimes called an application transaction)
that does not actually hold locks in the database, but that supports being
committed or rolled back atomically (in terms of its updates). Support for
this kind of transction is not officially in JPA, and IMO FlushMode.MANUAL
is not the right answer.
The reason why Seam even starts transactions at all is because it wants to
allow changes and it is assumed that changes must have a transaction to be
valid. This is kind of contrary to using transactions at all if the
transactions do not provide the isolation that separate transactions are
meant to imply.
Two features of JPA are:
a) reads may be performed outside a transaction
b) in an extended persistence context writes may actually be performed
outside a transaction on objects already managed, and the next time a
transaction is committed then the writes will be committed to the
database.
Note that b) is bordering on being in violation of the opposite of what
FlushMode.MANUAL does, because b) implies that all of the changes made
before the transaction begins get batched together and committed as part
of the next transaction, meaning that changes made outside the transaction
end up being committed as part of the transaction. We do not have a
solution for this problem yet in the spec, and I view it as less evil than
FlushMode.MANUAL, but still obviously less than ideal.
A better approach would be to
So, one approach (perhaps more suited to JPA, as it currently is) would be
to read in the entities outside a transaction, modify them as you see fit,
and then when the transaction is ready to be committed, begin and commit a
transaction. Not very good style, though.
A better approach would be to start a single transaction, use
FlushMode.COMMIT, and cause all of the reads to use a non-transactional
connection (ensuring that no PKs are generated, and that no updates occur).
This is the default mode that TopLink has traditionally adopted, and is
the most scalable in the event that you have a single transaction, and all
of the db updates (and db locks) are deferred until commit time.
|
|
| |
| Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376888 is a reply to message #376885] |
Wed, 23 July 2008 11:57 |
| Eclipse User |
|
|
|
Originally posted by: luxspes.yahoo.com
Hi!
Thanks for answering.
I think what you are forgetting is that transactions are not only for
writing data in to the database, they are also there to warrant read
consistency.
I know that support for conversational transactions is not officially in
the JPA, that is why I am asking here how to achive that effect with
EclipseLink proprietary API, I don't want to have a FlushMode.MANUAL in
EclipseLink, I just want something that is functionally equivalent.
The reason why Seam starts transactions is *not only* because it is
assumed that changes must have a transaction, but also because
transactions are needed for reading data.
If I issue 2 queries while rendering my page, and their data is
interrelated, and between the first and the second query another user
commits a changes, my 2 queries will return inconsistent data... How is
that handled in EclipseLink?
User A Query 1: select sum(R) from XXXX where A = Z
User B Modification: update XXX set A = Q where P = T
User A Query 2: select avg(R) from XXXX where A = Z
AFAIK I need transactions for Query 1 and Query 2 to be consistent... am I
wrong?
Unless a rdbms has no transaction support (and then we should be asking
ourselves if it should be called a rdbms) all DML operations are always
performed inside a transaction (what you call non-transactional is really
auto-transactional, each operation on its own individual transaction). So
saying that: reads may be performed outside a transaction is just plain
wrong.
Now, saying that reads may be performed in auto-transaction mode with one
transaction automatically started and commited for each operation is much
more accurate, and it opens the door for the following problem: What if I
want to make a group of read operations inside a transaction to make them
consistent? is it just plain impossible to that in EclipseLink? or am I
wrong to think that is a very valuable functionality?
Regards,
|
|
| |
| Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376890 is a reply to message #376888] |
Wed, 23 July 2008 17:08 |
| Eclipse User |
|
|
|
(Note: I have indeed been a little free and easy in my references to
transactions. I have in general been referring to the JTA or transaction
started by the application (eg JTA), not the database. I will distinguish,
though, where necessary, if it matters.)
I'm not forgetting about read consistency at all. If you are not making
any changes, or do not care whether those changes are reflected in your
query results, and are using the default isolation level anyway then you
don't need a transaction to be started by the app for reading. (You
obviously get a separate database transaction for each read that gets
auto-committed by the JDBC driver, but that is neither interesting nor
relevant).
You are confusing transactions with isolation. A DB transaction
(associated with the tx started by the app) may have any isolation level,
and by default it is typically READ_COMMITTED. This means that even though
you may be in a transaction your two queries will still return different
results because once the results of the intervening operation from User B
have been committed they are visible to the User A transaction. You need
to increase the isolation level to RR in order to be protected from
non-repeatable reads, and then you still wouldn't be protected from
phantom reads (if User B were to insert a new record with A = Z). To be
protected from that you would have to set your isolation to SERIALIZABLE.
The funny thing is that in the case you are talking about where Seam puts
each request in a different transaction then the entire conversation is
going to span multiple transactions anyway, so even if you did want to
take the hit and raise your isolation level then you would get your
"inconsistencies" across requests within the entire conversation.
You can do virtually anything in EclipseLink, including finding a way to
not flush when a transaction is committed. I just can't recommend doing
it, and I think the solution would be fairly ugly. The question is whether
you can get Seam to work with other (and in my opinion better) models of
operation. It may be dependent on its own transactional expectations of
committing and not flushing, but I honestly don't know if that is the case
or not.
|
|
|
Goto Forum:
Current Time: Wed Jul 23 03:49:15 EDT 2025
Powered by FUDForum. Page generated in 0.14992 seconds |
Home