Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
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 #376346 is a reply to message #376345] Tue, 15 July 2008 06:07 Go to previous messageGo to next message
Doug Clarke is currently offline Doug Clarke
Messages: 155
Registered: July 2009
Senior Member
Using EclipseLink JPA within SEAM is definitely interesting. While JSR 299
is an attempt to standardize what they have built in SEAM I always
considered SEAM itself to be tightly coupled to Hibernate.

I am wondering what the difference is between FlushMode.MANUAL and
FlushMode.COMMIT with App-Managed-TX(Non-JTA) and EclipseLink's conforming
queries. Would this not give you the same net effect where the in-memory
transaction (UnitOfWork) remains indefinitely while you perform reads,
modify managed entities, create new entities, and register entities for
removal? Then when you do call commit EclipseLink will begin the
transaction and perform all SQL UPDATE/INSERT/DELETE calls (with
configured locking semantics in use)?

Doug
Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376347 is a reply to message #376346] Tue, 15 July 2008 11:49 Go to previous messageGo to next message
Eclipse User
Originally posted by: luxspes.yahoo.com

Hi!
Well Seam authors say that, why in their opinion Hibernate is the best JPA
to use with Seam, it is possible to use it with any other JPA framework,
of course they remind you that if you use other JPA framework you will
miss FlushModeType.MANUAL .

To use EclipseLink all they say I need to do is to inherit from
org.jboss.seam.persistence.PersistenceProvider and reimplement the method:

@Override
public void setFlushModeManual(EntityManager entityManager) {
}

Now, I also don't quite get what is the difference between
FlushMode.MANUAL and FlushMode.COMMIT with App-Managed-TX(Non-JTA) and
EclipseLink's conforming queries... perhaps all that needs to be done is
to create some kind of adapter for EclipseLink that will disable sending
changes to the database when commit is called (and that will only send
them when flush() is called) is that possible? Perhaps with some
transaction nesting? (The important here is also to avoid locking stuff in
the database during the Seam Conversation)

Regards,
Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376348 is a reply to message #376346] Tue, 15 July 2008 12:07 Go to previous messageGo to next message
Eclipse User
Originally posted by: luxspes.yahoo.com

Hi!

I have been re-reading my hiberanate and seam books, and so far what I
think is that Seam runs each request response cycle that queries the
database inside a transaction, to warrant transactional consistency
(repeatable reads and stuff like that) at the end it will call commit to
end the transaction successfully (but without writing stuff to the
database).

I think that is why FlushModeType.MANUAL is needed because Seam may start
and commit serveral transactions, and they way to tell the JPA provider
that "this is just read only transaction, so please do not persist
anything on commit" is to use FlushModeType.MANUAL.

So, can you provide me with some guidance on how could I create an adapter
that enables that kind of functionality for EclipseLink?

Regards,
Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376359 is a reply to message #376348] Wed, 16 July 2008 21:00 Go to previous messageGo to next message
Sebastien Tardif is currently offline Sebastien Tardif
Messages: 4
Registered: July 2009
Junior Member
Conversations span many database connections. The ultimate goal is
actually to not hold on any database connection and be able to rollback
anything, so no write connection can be involved before the end.
Repeatable read/isolation are provided by the unit of work. Because you
use the same unit of work the objects are not detached so you can load
lazy references in other subsequent request during the same conversation.
TopLink doesn't keep reference to database connection after read query so
it's already close to be conversation compliant.

So if you find a way to disable all flushing that TopLink may trigger and
you a way to keep the unit of work between browser request, then you have
a "Seam" like conversation.
Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376360 is a reply to message #376348] Thu, 17 July 2008 07:46 Go to previous messageGo to next message
Doug Clarke is currently offline Doug Clarke
Messages: 155
Registered: July 2009
Senior Member
Having a mode where changes made within a transaction are not committed
seems very odd to me.

Making changes within a entity manager acting as an extended persistence
context where the complete set of conversation changes are committed in a
single transaction does make sense and is very common. JPA supports this
through its support for joining of an extended persistence context with a
transaction.

You just need to find a way to have SEAM avoid beginning and committing
transactions for each interaction in the conversation where the
application does not want the changes committed.

Doug
Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376362 is a reply to message #376360] Thu, 17 July 2008 08:34 Go to previous messageGo to next message
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 Go to previous messageGo to next message
Mike Keith is currently offline Mike Keith
Messages: 207
Registered: July 2009
Senior Member
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 #376886 is a reply to message #376885] Tue, 22 July 2008 14:33 Go to previous messageGo to next message
Mike Keith is currently offline Mike Keith
Messages: 207
Registered: July 2009
Senior Member
Seems that there was a jiggle in the last post. Second last paragraph
should have been:

"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."
Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376888 is a reply to message #376885] Wed, 23 July 2008 11:57 Go to previous messageGo to next message
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 #376889 is a reply to message #376888] Wed, 23 July 2008 12:20 Go to previous messageGo to next message
Eclipse User
Originally posted by: luxspes.yahoo.com

Made a little mistake myself, the end of last paragraph should have been:

What if I want to do a group of consistent read operations? Do I need to
do them inside a transaction? is it just plain impossible to that in
EclipseLink? Am I wrong to think that is a very valuable functionality?
Re: JBoss Seam: FlushModeType.MANUAL for EclipseLink/TopLink [message #376890 is a reply to message #376888] Wed, 23 July 2008 17:08 Go to previous message
Mike Keith is currently offline Mike Keith
Messages: 207
Registered: July 2009
Senior Member
(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.
Previous Topic:eclipse 1.0M6 to 1.0: IllegalAccessError
Next Topic:PreUpdate not be called at merge
Goto Forum:
  


Current Time: Sun Apr 20 06:54:33 EDT 2014

Powered by FUDForum. Page generated in 0.02901 seconds