Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » not so lazy / locking a record
not so lazy / locking a record [message #384235] Mon, 08 December 2008 10:29 Go to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
I have Eclipselink running with lazy locking using a version (integer). During (or better: just before) committing a change, a trigger is used to generate other entities. These entities are allocations on a stock; records are inserted, update or removed to allocate portions of the stock.

Usually orders will involve the same articles (we are in a very fashion sensitive business, so some article are hot and will be ordered by everyone), which will mean that using lazy locking has a high chance of conflicts.

In the JDBC version I use a simple synchronization mechanism; each stock item has one central record, by executing a dummy update statement on that central record I "lock" the particular batch. If someone else has that record already locked, I have the database set to wait max X seconds. A allocation run usually takes only a few seconds, so after the other lock holder is finished, I get access to that stock. Because all stock items are scanned sequentially, there is no risc of deadlock.

Now I need to do something similar using Eclipselink. I have though of a few possible approaches:
1. flush changes: do a dummy action on the central entity, similar to the JDBC approach, and have that change flushed immediately so the lock is attempted
2. use a central locking server
3. use direct JDBC and execute the lock SQL

The problem with 1. is that I only want to flush only that dummy lock statement and not all other changes. Eclipselink probably will also flush all related entities, since my BM is cascade-setup like that.

The problem with 2. is that I do not like to add another single-point-of-failure just for this.

The problem with 3. is that I have to make sure it is the same connection that will be used by Eclipse to write the changes, otherwise my lock will block the persist or I have a gap where another allocation run will step into.

I'm leaning to see if 3. can be done. Does anyone have a suggestion / experience with such an approach?

Tom
Re: not so lazy / locking a record [message #384238 is a reply to message #384235] Tue, 09 December 2008 10:01 Go to previous messageGo to next message
James Sutherland is currently offline James Sutherland
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

What database are you using? You could use pessimistic locking in
EclipseLink using the "eclipselink.pessimistic-lock"="Lock" Query hint.
The EclipseLink 1.1 dev stream also has support for the JPA 2.0
pessimistic lock option.

Otherwise you could acquire an optimistic write lock and flush the
transaction. Just make sure you acquire the lock up front to avoid other
change being flushed.

You could also just issue a native SQL query, or an update-all query to
force a lock on the row.

See also,
http://en.wikibooks.org/wiki/Java_Persistence/Locking

---
James
http://www.nabble.com/EclipseLink---Users-f26658.html


James : Wiki : Book : Blog : Twitter
Re: not so lazy / locking a record [message #384242 is a reply to message #384238] Tue, 09 December 2008 13:45 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
WOA. That are a lot of options!

I'm using Informix IDS 10.

You basically already know the situation from a different thread: user makes a change, as a result new entities are created (that are not persist in a @PrePersist event), and during the creation of these entities locking is required.

Thanks
Re: not so lazy / locking a record [message #384355 is a reply to message #384238] Mon, 15 December 2008 06:42 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
So far a "createNativeQuery" seems to work just fine. More testing is required.
Re: not so lazy / locking a record [message #385415 is a reply to message #384355] Fri, 30 January 2009 07:02 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
tbee wrote:
> So far a "createNativeQuery" seems to work just fine. More testing is
> required.

Bummer. The native query is executed through a different connection though which the reads are done. So the lock blocks queries further down the code. Is it possible to force the same connection for write and reads? JDBC_READ_CONNECTIONS_*, etc?
Re: not so lazy / locking a record [message #385416 is a reply to message #385415] Fri, 30 January 2009 14:28 Go to previous messageGo to next message
Gordon Yorke is currently offline Gordon Yorke
Messages: 77
Registered: July 2009
Member
There is an easy way and a not so easy way. The easiest is to use
"eclipselink.transaction.join-existing" = "true" when getting the
EntityManager. This will cause all queries to use the transactional write
connection.

If you want advanced functionality and want to have only some queries on
this EM use the write connection then get the EM with
"eclipselink.jdbc.exclusive-connection.mode" = "isolated" then when
executing the query set the hint ""eclipselink.exclusive-connection" =
"true" and this query will execute through the write connection.

If you are performing a pessimistic lock then I recommend the first
("join-existing") option as further database access should be in the same
transaction once the lock has been acquired.
--Gordon
Re: not so lazy / locking a record [message #385418 is a reply to message #385416] Sat, 31 January 2009 04:27 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
During save I need to make sure I am the only one accessing a small tree of records, so I try to obtain a pessimistic lock on a central record, representing that small tree.
The locking is done in a order-by fashion, so deadlocks are not possible.

99.9% of what I do is optimistic locking, but for these entities there is a very big chance of change-conflicts, so for this entity I want pessimistic locking.

I'll give the join-existing a try monday.

Tom


Gordon Yorke wrote:
> There is an easy way and a not so easy way. The easiest is to use
> "eclipselink.transaction.join-existing" = "true" when getting the
> EntityManager. This will cause all queries to use the transactional
> write connection.
> If you want advanced functionality and want to have only some queries on
> this EM use the write connection then get the EM with
> "eclipselink.jdbc.exclusive-connection.mode" = "isolated" then when
> executing the query set the hint ""eclipselink.exclusive-connection" =
> "true" and this query will execute through the write connection.
>
> If you are performing a pessimistic lock then I recommend the first
> ("join-existing") option as further database access should be in the
> same transaction once the lock has been acquired.
> --Gordon
>
Re: not so lazy / locking a record [message #385419 is a reply to message #384238] Mon, 02 February 2009 04:10 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
> What database are you using? You could use pessimistic locking in
> EclipseLink using the "eclipselink.pessimistic-lock"="Lock" Query hint.


// eclipselink.pessimistic-lock
Query lQuery = lEntityManager.createQuery("select t from Batch t where t.iBatchnr=:batchnr");
lQuery.setParameter("batchnr", getBatchnr());
lQuery.setHint(QueryHints.PESSIMISTIC_LOCK, PessimisticLock.Lock);
lQuery.getResultList();


That seems to result in repeatative behavior. Just for illustration, note how it rereads the same article (setInt=82) and articletype (setInt=3) over and over again. Don't know why. I'm going to try the eclipselink.transaction.join-existing with native query now.

2009-02-02 09:49:21,565 DEBUG #7559841[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,565 DEBUG #7559841[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,628 DEBUG #9237505[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,628 DEBUG #9237505[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,628 DEBUG #11498117[C7655982]: [1] setInt=35743 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,628 DEBUG #11498117[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,628 DEBUG #24320815[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,628 DEBUG #24320815[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,659 DEBUG #17941374[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,659 DEBUG #17941374[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,659 DEBUG #7441564[C7655982]: [1] setInt=7050 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,659 DEBUG #7441564[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,659 DEBUG #8181516[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,659 DEBUG #8181516[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,659 DEBUG #23649128[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,722 DEBUG #23649128[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,737 DEBUG #19730165[C7655982]: [1] setInt=34913 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,737 DEBUG #19730165[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,753 DEBUG #29597917[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,753 DEBUG #29597917[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,753 DEBUG #3751317[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,753 DEBUG #3751317[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,769 DEBUG #18322396[C7655982]: [1] setInt=36149 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,769 DEBUG #18322396[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,769 DEBUG #11815874[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,769 DEBUG #11815874[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,769 DEBUG #13974914[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,769 DEBUG #13974914[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,784 DEBUG #4394287[C7655982]: [1] setInt=35503 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,800 DEBUG #4394287[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,800 DEBUG #30518135[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,800 DEBUG #30518135[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,800 DEBUG #4430647[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,800 DEBUG #4430647[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,800 DEBUG #5570831[C7655982]: [1] setInt=36087 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,815 DEBUG #5570831[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,815 DEBUG #18572097[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,815 DEBUG #18572097[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,831 DEBUG #24628657[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,831 DEBUG #24628657[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,831 DEBUG #1011357[C7655982]: [1] setInt=34913 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,831 DEBUG #1011357[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,847 DEBUG #22650680[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,847 DEBUG #22650680[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,847 DEBUG #2926860[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,847 DEBUG #2926860[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,847 DEBUG #3635144[C7655982]: [1] setInt=35743 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,847 DEBUG #3635144[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,862 DEBUG #22674268[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,878 DEBUG #22674268[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,878 DEBUG #18522450[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,878 DEBUG #18522450[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,878 DEBUG #10668819[C7655982]: [1] setInt=36087 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,878 DEBUG #10668819[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,878 DEBUG #8167849[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,894 DEBUG #8167849[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 09:49:21,894 DEBUG #8076068[C7655982]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 09:49:21,894 DEBUG #8076068[C7655982]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 09:49:21,909 DEBUG #25647746[C7655982]: [1] setInt=2 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 09:49:21,909 DEBUG #25647746[C7655982]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 09:49:21,909 DEBUG #12814788[C7655982]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 09:49:21,909 DEBUG #12814788[C7655982]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
Re: not so lazy / locking a record [message #385420 is a reply to message #385416] Mon, 02 February 2009 05:54 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
> There is an easy way and a not so easy way. The easiest is to use
> "eclipselink.transaction.join-existing" = "true" when getting the
> EntityManager. This will cause all queries to use the transactional
> write connection.

I like easy...

static public EntityManager createEntityManager(EntityManagerFactory entityManagerFactory)
{
Map<String, String> lOptions = new HashMap<String, String>();
lOptions.put(org.eclipse.persistence.config.EntityManagerPro perties.JOIN_EXISTING_TRANSACTION, "true");
return EntityManagerExtender.wrap( entityManagerFactory.createEntityManager(lOptions) );
}


The lock code:

// NativeQuery
Query lQuery = lEntityManager.createNativeQuery("update batch set batchnr = batchnr where batchnr = " + getBatchnr());
lQuery.executeUpdate();


My test code:

// entitymanagerfactory
EntityManagerFactory lEntityManagerFactory = BM.createEntityManagerFactory(com.informix.jdbc.IfxDriver.cl ass, " jdbc:informix-sqli://toeu_reinders:1527/reinders:INFORMIXSER VER=ol_ids10;DB_LOCALE=en_us.utf8", "user", "user");

// entitymanager
EntityManager lEntityManager = BM.createEntityManager(lEntityManagerFactory);

// setup the application
org.tbee.util.jpa.EntityManagerFinderSingleton.register();
org.tbee.util.jpa.EntityManagerFinderSingleton.setEntityMana ger(lEntityManager);
AbstractBean.setGlobalDwhby(java.math.BigInteger.valueOf(1)) ;

// emulate user entry: create new transfer and transferline
Batchtransfer lBatchtransfer = new Batchtransfer();
lEntityManager.persist( lBatchtransfer );
Batchtransferline lBatchtransferline = new Batchtransferline();
lEntityManager.persist( lBatchtransferline );
lBatchtransferline.setBatchtransfer( lBatchtransfer );
lBatchtransferline.setArticle( Article.findByPK(82) );
lBatchtransferline.setFromAmount( BigInteger.valueOf(30) );
lBatchtransferline.setFromBatchtype( Batchtype.findByDescription("GEROLD") );
lBatchtransferline.setToAmount( BigInteger.valueOf(20) );
lBatchtransferline.setToBatchtype( Batchtype.findByDescription("A1/1") );

// commit
EntityManagerExtender.executeNextClearWithoutClearingRemoved Entities(lEntityManager); // if we're using EntityManagerExtender (which we should)...
lEntityManager.clear(); // prevent errors from a previous store session (not rollbacked optimistic lock increments) to screw things up
lEntityManager.getTransaction().begin();
lBatchtransfer = lEntityManager.merge(lBatchtransfer);
lBatchtransferline.updateBatchcount(); // emulate application event "afterUpdate"
lEntityManager.getTransaction().commit();

// close shop
lEntityManager.close();
lEntityManagerFactory.close();


Please note that only one EM is created (second line), no where in the code another EM is created, plus there is only one transaction. I've validated that the same EM is actually used.
The problem I run into is that is switches connections. I've included almost the complete trace, but marked the relative positions with [=======: plus some comment].
The problem occurs when executing the "updateBatchcount()" call in the code above; some how it switches connection, it never reaches the commit.
I could include the code for updateBatchcount, but I do not think it will contribute; it is just a some what confusing bunch of finds, loops and property modifications.
What could make it switch connection?



Java HotSpot(TM) Client VM warning: increase O_BUFLEN in ostream.hpp -- output truncated
[EL Warning]: 2009.02.02 11:22:54.269--ServerSession(11110706)--Ignoring default serialization on element [protected volatile java.lang.Boolean nl.reinders.bm.generated.Task.iCompleted] within entity class [class nl.reinders.bm.Task] since a @Convert is specified.
....
[EL Warning]: 2009.02.02 11:22:57.331--ServerSession(11110706)--Ignoring default serialization on element [protected volatile java.lang.Boolean nl.reinders.bm.generated.RelationstandToFrame.iAllcodes] within entity class [class nl.reinders.bm.RelationstandToFrame] since a @Convert is specified.
java.vm.version=11.0-b12-fastdebug
IBM Informix JDBC Driver Version 3.50.JC3DE
2009-02-02 11:22:58,722 INFO nl.reinders.bm.BM.getEntityManagerFactorySettings(BM.java:38 ) Setting up a EntityManagerFactory to user @ jdbc:reinders:com.informix.jdbc.IfxDriver#jdbc:informix-sqli ://toeu_reinders:1527/reinders:INFORMIXSERVER=ol_ids10;DB_LOCALE=en_us.utf8
[EL Info]: 2009.02.02 11:23:06.847--ServerSession(11110706)--EclipseLink, version: Eclipse Persistence Services - 1.0.2 (Build 20081024)
[=======: below a connection is created / initialized, the connection is identified by the C22221117]
2009-02-02 11:23:07,472 DEBUG #21364283[C22221117]: executeUpdate( set lock mode to wait 30 ) returns #0: 0
2009-02-02 11:23:07,487 DEBUG #713167[C22221117]: executeUpdate( set isolation to committed read ) returns #0: 0
2009-02-02 11:23:07,503 DEBUG #21622849[C22221117]: executeUpdate( set role javaapp1 ) returns #0: 0
[EL Info]: 2009.02.02 11:23:08.675--ServerSession(11110706)--file:/C:/Documents%20 and%20Settings/user/My%20Documents/reinders/voorraad/contain er/bm/build/-reinders login successful
2009-02-02 11:23:09,909 DEBUG #31380681[C22221117]: [1] setBigDecimal=1 / java.math.BigDecimal / SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = >>>HERE<<< )
2009-02-02 11:23:10,003 DEBUG #31380681[C22221117]: executeQuery: SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = ?)
2009-02-02 11:23:10,144 DEBUG #5875509[C22221117]: [1] setBigDecimal=1 / java.math.BigDecimal / SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = >>>HERE<<< )
2009-02-02 11:23:10,237 DEBUG #5875509[C22221117]: executeQuery: SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = ?)
2009-02-02 11:23:10,237 DEBUG #12984448[C22221117]: [1] setBigDecimal=1 / java.math.BigDecimal / SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = >>>HERE<<< )
2009-02-02 11:23:10,237 DEBUG #12984448[C22221117]: executeQuery: SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = ?)
[=======: another connection is created / initialized, used for the sequence table]
2009-02-02 11:23:10,284 DEBUG #26179329[C732260]: executeUpdate( set lock mode to wait 30 ) returns #0: 0
2009-02-02 11:23:10,284 DEBUG #10714218[C732260]: executeUpdate( set isolation to committed read ) returns #0: 0
2009-02-02 11:23:10,284 DEBUG #7897563[C732260]: executeUpdate( set role javaapp1 ) returns #0: 0
2009-02-02 11:23:10,284 DEBUG #732260[C732260]: setAutoCommit( false )
2009-02-02 11:23:10,284 DEBUG #8449424[C732260]: executeUpdate( set constraints all deferred ) returns #0: 0
2009-02-02 11:23:10,300 DEBUG #30065658[C732260]: [1] setInt=1 / java.lang.Integer / UPDATE sequence SET seq_count = seq_count + >>>HERE<<< WHERE seq_name = ?
2009-02-02 11:23:10,315 DEBUG #30065658[C732260]: [2] setString=batchtransfernr / java.lang.String / UPDATE sequence SET seq_count = seq_count + ? WHERE seq_name = >>>HERE<<<
2009-02-02 11:23:10,362 DEBUG #30065658[C732260]: executeUpdate: UPDATE sequence SET seq_count = seq_count + ? WHERE seq_name = ?
2009-02-02 11:23:10,362 DEBUG #13579577[C732260]: [1] setString=batchtransfernr / java.lang.String / SELECT seq_count FROM sequence WHERE seq_name = >>>HERE<<<
2009-02-02 11:23:10,378 DEBUG #13579577[C732260]: executeQuery: SELECT seq_count FROM sequence WHERE seq_name = ?
2009-02-02 11:23:10,409 DEBUG #732260[C732260]: commit()
2009-02-02 11:23:10,409 DEBUG #24298619[C732260]: executeUpdate( set constraints all deferred ) returns #0: 0
2009-02-02 11:23:10,409 DEBUG #732260[C732260]: setAutoCommit( true )
[=======: a third connection is created / initialized, used for the sequence table]
2009-02-02 11:23:10,472 DEBUG #28378327[C16164994]: executeUpdate( set lock mode to wait 30 ) returns #0: 0
2009-02-02 11:23:10,487 DEBUG #28365628[C16164994]: executeUpdate( set isolation to committed read ) returns #0: 0
2009-02-02 11:23:10,519 DEBUG #24918414[C16164994]: executeUpdate( set role javaapp1 ) returns #0: 0
2009-02-02 11:23:10,519 DEBUG #16164994[C16164994]: setAutoCommit( false )
2009-02-02 11:23:10,519 DEBUG #4396348[C16164994]: executeUpdate( set constraints all deferred ) returns #0: 0
2009-02-02 11:23:10,519 DEBUG #3946484[C16164994]: [1] setInt=1 / java.lang.Integer / UPDATE sequence SET seq_count = seq_count + >>>HERE<<< WHERE seq_name = ?
2009-02-02 11:23:10,519 DEBUG #3946484[C16164994]: [2] setString=batchtransferlinenr / java.lang.String / UPDATE sequence SET seq_count = seq_count + ? WHERE seq_name = >>>HERE<<<
2009-02-02 11:23:10,519 DEBUG #3946484[C16164994]: executeUpdate: UPDATE sequence SET seq_count = seq_count + ? WHERE seq_name = ?
2009-02-02 11:23:10,550 DEBUG #33517025[C16164994]: [1] setString=batchtransferlinenr / java.lang.String / SELECT seq_count FROM sequence WHERE seq_name = >>>HERE<<<
2009-02-02 11:23:10,597 DEBUG #33517025[C16164994]: executeQuery: SELECT seq_count FROM sequence WHERE seq_name = ?
2009-02-02 11:23:10,597 DEBUG #16164994[C16164994]: commit()
2009-02-02 11:23:10,612 DEBUG #28054487[C16164994]: executeUpdate( set constraints all deferred ) returns #0: 0
2009-02-02 11:23:10,612 DEBUG #16164994[C16164994]: setAutoCommit( true )
[=======: we're back a the original connection, this is used in the "emulate user input"]
2009-02-02 11:23:10,675 DEBUG #7443611[C22221117]: [1] setBigDecimal=82 / java.math.BigDecimal / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 11:23:10,722 DEBUG #7443611[C22221117]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-02 11:23:10,784 DEBUG #11780687[C22221117]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-02 11:23:10,800 DEBUG #11780687[C22221117]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-02 11:23:10,847 DEBUG #1244162[C22221117]: [1] setInt=82 / java.lang.Integer / SELECT batchtransferlinenr, articlenr, batchtransfernr, from_batchtypenr, to_batchtypenr, from_amount, to_amount, reason, lazylock, dwhmodified, dwhby FROM batchtransferline WHERE (articlenr = >>>HERE<<< )
2009-02-02 11:23:10,862 DEBUG #1244162[C22221117]: executeQuery: SELECT batchtransferlinenr, articlenr, batchtransfernr, from_batchtypenr, to_batchtypenr, from_amount, to_amount, reason, lazylock, dwhmodified, dwhby FROM batchtransferline WHERE (articlenr = ?)
2009-02-02 11:23:10,878 DEBUG #12333359[C22221117]: [1] setInt=7 / java.lang.Integer / SELECT batchtransfernr, enteredby_employeenr, reason, createdon, lazylock, dwhmodified, dwhby FROM batchtransfer WHERE (batchtransfernr = >>>HERE<<< )
2009-02-02 11:23:10,878 DEBUG #12333359[C22221117]: executeQuery: SELECT batchtransfernr, enteredby_employeenr, reason, createdon, lazylock, dwhmodified, dwhby FROM batchtransfer WHERE (batchtransfernr = ?)
2009-02-02 11:23:10,878 DEBUG #9531264[C22221117]: [1] setBigDecimal=1 / java.math.BigDecimal / SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = >>>HERE<<< )
2009-02-02 11:23:10,878 DEBUG #9531264[C22221117]: executeQuery: SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = ?)
2009-02-02 11:23:10,894 DEBUG #26127350[C22221117]: [1] setInt=24 / java.lang.Integer / SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = >>>HERE<<< )
2009-02-02 11:23:10,894 DEBUG #26127350[C22221117]: executeQuery: SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = ?)
2009-02-02 11:23:10,909 DEBUG #19833309[C22221117]: [1] setInt=1 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 11:23:10,972 DEBUG #19833309[C22221117]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 11:23:10,972 DEBUG #33066941[C22221117]: [1] setInt=2 / java.lang.Integer / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 11:23:10,972 DEBUG #33066941[C22221117]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 11:23:11,019 DEBUG #8855141[C22221117]: [1] setString=GEROLD / java.lang.String / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (description = >>>HERE<<< )
2009-02-02 11:23:11,081 DEBUG #8855141[C22221117]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (description = ?)
2009-02-02 11:23:11,097 DEBUG #24758223[C22221117]: [1] setString=A1/1 / java.lang.String / SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (description = >>>HERE<<< )
2009-02-02 11:23:11,112 DEBUG #24758223[C22221117]: executeQuery: SELECT batchtypenr, description, lazylock, dwhmodified, dwhby, pricerulecode FROM batchtype WHERE (description = ?)
[=======: a fourth connection is created, upon starting the transaction]
2009-02-02 11:23:11,175 DEBUG #1389308[C18239702]: executeUpdate( set lock mode to wait 30 ) returns #0: 0
2009-02-02 11:23:11,175 DEBUG #6451154[C18239702]: executeUpdate( set isolation to committed read ) returns #0: 0
2009-02-02 11:23:11,175 DEBUG #15255515[C18239702]: executeUpdate( set role javaapp1 ) returns #0: 0
2009-02-02 11:23:11,175 DEBUG #18239702[C18239702]: setAutoCommit( false )
2009-02-02 11:23:11,175 DEBUG #23231510[C18239702]: executeUpdate( set constraints all deferred ) returns #0: 0
2009-02-02 11:23:11,190 DEBUG #23939920[C18239702]: [1] setBigDecimal=19 / java.math.BigDecimal / SELECT batchtransfernr, enteredby_employeenr, reason, createdon, lazylock, dwhmodified, dwhby FROM batchtransfer WHERE (batchtransfernr = >>>HERE<<< )
2009-02-02 11:23:11,190 DEBUG #23939920[C18239702]: executeQuery: SELECT batchtransfernr, enteredby_employeenr, reason, createdon, lazylock, dwhmodified, dwhby FROM batchtransfer WHERE (batchtransfernr = ?)
2009-02-02 11:23:11,253 DEBUG #33468166[C18239702]: [1] setBigDecimal=1 / java.math.BigDecimal / SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = >>>HERE<<< )
2009-02-02 11:23:11,269 DEBUG #33468166[C18239702]: executeQuery: SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = ?)
2009-02-02 11:23:11,284 DEBUG #11994696[C18239702]: [1] setBigDecimal=1 / java.math.BigDecimal / SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = >>>HERE<<< )
2009-02-02 11:23:11,284 DEBUG #11994696[C18239702]: executeQuery: SELECT employeenr, name, lazylock, dwhmodified, dwhby FROM employee WHERE (employeenr = ?)
2009-02-02 11:23:11,284 DEBUG #8762992[C18239702]: [1] setBigDecimal=8 / java.math.BigDecimal / SELECT batchtransferlinenr FROM batchtransferline WHERE (batchtransferlinenr = >>>HERE<<< )
2009-02-02 11:23:11,300 DEBUG #8762992[C18239702]: executeQuery: SELECT batchtransferlinenr FROM batchtransferline WHERE (batchtransferlinenr = ?)
2009-02-02 11:23:11,300 DEBUG #13482579[C18239702]: [1] setBigDecimal=82 / java.math.BigDecimal / SELECT articlenr FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-02 11:23:11,300 DEBUG #13482579[C18239702]: executeQuery: SELECT articlenr FROM article WHERE (articlenr = ?)
2009-02-02 11:23:11,315 DEBUG #5585368[C18239702]: [1] setBigDecimal=2 / java.math.BigDecimal / SELECT batchtypenr FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 11:23:11,315 DEBUG #5585368[C18239702]: executeQuery: SELECT batchtypenr FROM batchtype WHERE (batchtypenr = ?)
2009-02-02 11:23:11,331 DEBUG #30731957[C18239702]: [1] setBigDecimal=36102 / java.math.BigDecimal / SELECT batchtypenr FROM batchtype WHERE (batchtypenr = >>>HERE<<< )
2009-02-02 11:23:11,331 DEBUG #30731957[C18239702]: executeQuery: SELECT batchtypenr FROM batchtype WHERE (batchtypenr = ?)
[=======: entering "updateBatchcount()"]
2009-02-02 11:23:11,378 DEBUG #824654[C18239702]: [1] setBigDecimal=0 / java.math.BigDecimal / SELECT batchnr, articlenr, batchtype, costprice, creationdate, lazylock, _amount, dwhmodified, dwhby, inserted FROM batch WHERE (((_amount > >>>HERE<<< ) AND (articlenr = ?)) AND (batchtype = ?)) ORDER BY batchnr ASC
2009-02-02 11:23:11,378 DEBUG #824654[C18239702]: [2] setBigDecimal=82 / java.math.BigDecimal / SELECT batchnr, articlenr, batchtype, costprice, creationdate, lazylock, _amount, dwhmodified, dwhby, inserted FROM batch WHERE (((_amount > ?) AND (articlenr = >>>HERE<<< )) AND (batchtype = ?)) ORDER BY batchnr ASC
2009-02-02 11:23:11,378 DEBUG #824654[C18239702]: [3] setBigDecimal=2 / java.math.BigDecimal / SELECT batchnr, articlenr, batchtype, costprice, creationdate, lazylock, _amount, dwhmodified, dwhby, inserted FROM batch WHERE (((_amount > ?) AND (articlenr = ?)) AND (batchtype = >>>HERE<<< )) ORDER BY batchnr ASC
2009-02-02 11:23:12,050 DEBUG #824654[C18239702]: executeQuery: SELECT batchnr, articlenr, batchtype, costprice, creationdate, lazylock, _amount, dwhmodified, dwhby, inserted FROM batch WHERE (((_amount > ?) AND (articlenr = ?)) AND (batchtype = ?)) ORDER BY batchnr ASC
[=======: locking a batch!]
2009-02-02 11:23:12,081 DEBUG #7477605[C18239702]: executeUpdate: update batch set batchnr = batchnr where batchnr = 575356
2009-02-02 11:23:12,097 DEBUG #33038931[C18239702]: [1] setInt=575356 / java.lang.Integer / SELECT batchcountnr, batchnr, to_amount_batchtransferlinenr, from_amount_batchtransferlinenr, batchdate, amount, description, rollentodolinenr, rollendonelinenr, lazylock, dwhmodified, dwhby FROM batchcount WHERE (batchnr = >>>HERE<<< )
2009-02-02 11:23:12,144 DEBUG #33038931[C18239702]: executeQuery: SELECT batchcountnr, batchnr, to_amount_batchtransferlinenr, from_amount_batchtransferlinenr, batchdate, amount, description, rollentodolinenr, rollendonelinenr, lazylock, dwhmodified, dwhby FROM batchcount WHERE (batchnr = ?)
[=======: even the sequence shares the connection]
2009-02-02 11:23:12,175 DEBUG #30526967[C18239702]: [1] setInt=1 / java.lang.Integer / UPDATE sequence SET seq_count = seq_count + >>>HERE<<< WHERE seq_name = ?
2009-02-02 11:23:12,175 DEBUG #30526967[C18239702]: [2] setString=batchcountnr / java.lang.String / UPDATE sequence SET seq_count = seq_count + ? WHERE seq_name = >>>HERE<<<
2009-02-02 11:23:12,175 DEBUG #30526967[C18239702]: executeUpdate: UPDATE sequence SET seq_count = seq_count + ? WHERE seq_name = ?
2009-02-02 11:23:12,175 DEBUG #32579087[C18239702]: [1] setString=batchcountnr / java.lang.String / SELECT seq_count FROM sequence WHERE seq_name = >>>HERE<<<
2009-02-02 11:23:12,175 DEBUG #32579087[C18239702]: executeQuery: SELECT seq_count FROM sequence WHERE seq_name = ?
[=======: hey, what is this? Why are we back at the pre-transaction connection???? We have not yet reached the "commit"]
2009-02-02 11:23:12,175 DEBUG #26194839[C22221117]: [1] setInt=82 / java.lang.Integer / SELECT batchnr, articlenr, batchtype, costprice, creationdate, lazylock, _amount, dwhmodified, dwhby, inserted FROM batch WHERE (articlenr = >>>HERE<<< )
2009-02-02 11:23:12,206 DEBUG #26194839[C22221117]: executeQuery: SELECT batchnr, articlenr, batchtype, costprice, creationdate, lazylock, _amount, dwhmodified, dwhby, inserted FROM batch WHERE (articlenr = ?)

[=======: this is informix's way to tell the user it ran into a lock and timed out]
Exception in thread "main" Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 1.0.2 (Build 20081024)): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Could not position within a table (informix.batch).
Error Code: -243
Call: SELECT batchnr, articlenr, batchtype, costprice, creationdate, lazylock, _amount, dwhmodified, dwhby, inserted FROM batch WHERE (articlenr = ?)
bind => [82]
Query: ReadAllQuery(nl.reinders.bm.Batch)
at org.eclipse.persistence.exceptions.DatabaseException.sqlExce ption(DatabaseException.java:322)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAcce ssor.basicExecuteCall(DatabaseAccessor.java:646)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAcce ssor.executeCall(DatabaseAccessor.java:500)
at org.eclipse.persistence.sessions.server.ServerSession.execut eCall(ServerSession.java:522)
at org.eclipse.persistence.internal.sessions.IsolatedClientSess ion.executeCall(IsolatedClientSession.java:134)
at org.eclipse.persistence.internal.queries.DatasourceCallQuery Mechanism.executeCall(DatasourceCallQueryMechanism.java:204)
at org.eclipse.persistence.internal.queries.DatasourceCallQuery Mechanism.executeCall(DatasourceCallQueryMechanism.java:190)
at org.eclipse.persistence.internal.queries.DatasourceCallQuery Mechanism.executeSelectCall(DatasourceCallQueryMechanism.jav a:261)
at org.eclipse.persistence.internal.queries.DatasourceCallQuery Mechanism.selectAllRows(DatasourceCallQueryMechanism.java:59 4)
at org.eclipse.persistence.internal.queries.ExpressionQueryMech anism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2 506)
at org.eclipse.persistence.internal.queries.ExpressionQueryMech anism.selectAllRows(ExpressionQueryMechanism.java:2464)
at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLe velReadQuery(ReadAllQuery.java:478)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute DatabaseQuery(ObjectLevelReadQuery.java:879)
at org.eclipse.persistence.queries.DatabaseQuery.execute(Databa seQuery.java:666)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute (ObjectLevelReadQuery.java:840)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAll Query.java:456)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute InUnitOfWork(ObjectLevelReadQuery.java:902)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.int ernalExecuteQuery(UnitOfWorkImpl.java:2587)
at org.eclipse.persistence.internal.sessions.AbstractSession.ex ecuteQuery(AbstractSession.java:1178)
at org.eclipse.persistence.internal.sessions.AbstractSession.ex ecuteQuery(AbstractSession.java:1162)
at org.eclipse.persistence.internal.indirection.QueryBasedValue Holder.instantiate(QueryBasedValueHolder.java:77)
at org.eclipse.persistence.internal.indirection.QueryBasedValue Holder.instantiate(QueryBasedValueHolder.java:67)
at org.eclipse.persistence.internal.indirection.DatabaseValueHo lder.getValue(DatabaseValueHolder.java:83)
at org.eclipse.persistence.internal.indirection.UnitOfWorkValue Holder.instantiateImpl(UnitOfWorkValueHolder.java:161)
at org.eclipse.persistence.internal.indirection.UnitOfWorkValue Holder.instantiate(UnitOfWorkValueHolder.java:230)
at org.eclipse.persistence.internal.indirection.DatabaseValueHo lder.getValue(DatabaseValueHolder.java:83)
at org.eclipse.persistence.indirection.IndirectList.buildDelega te(IndirectList.java:213)
at org.eclipse.persistence.indirection.IndirectList.getDelegate (IndirectList.java:379)
at org.eclipse.persistence.indirection.IndirectList.contains(In directList.java:310)
at nl.reinders.bm.generated.Article.addBatchesWhereIAmArticle(A rticle.java:200)
at nl.reinders.bm.generated.Batch.setArticle(Batch.java:212)
at nl.reinders.bm.Batchcount.changeContibutionTo(Batchcount.jav a:359)
at nl.reinders.bm.Batchtransferline.updateBatchcount(Batchtrans ferline.java:137)
at nl.reinders.bm.BMTestToplink.main(BMTestToplink.java:64)
Caused by: java.sql.SQLException: Could not position within a table (informix.batch).
at com.informix.jdbc.IfxSqli.a(IfxSqli.java:3449)
at com.informix.jdbc.IfxSqli.E(IfxSqli.java:3762)
at com.informix.jdbc.IfxSqli.dispatchMsg(IfxSqli.java:2574)
at com.informix.jdbc.IfxSqli.receiveMessage(IfxSqli.java:2490)
at com.informix.jdbc.IfxSqli.j(IfxSqli.java:2172)
at com.informix.jdbc.IfxSqli.getaRow(IfxSqli.java:4480)
at com.informix.jdbc.IfxResultSet.next(IfxResultSet.java:523)
at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.tbee.util.jdbc.ResultSet.invoke(ResultSet.java:79)
at $Proxy34.next(Unknown Source)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAcce ssor.basicExecuteCall(DatabaseAccessor.java:622)
... 32 more
Caused by: java.sql.SQLException: ISAM error: Lock Timeout Expired
at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:4 07)
at com.informix.jdbc.IfxSqli.E(IfxSqli.java:3767)
... 43 more
Brainflash: not so lazy / locking a record - EM remembering [message #385421 is a reply to message #385420] Mon, 02 February 2009 06:07 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
> What could make it switch connection?

I tried this, to see if the sequence was the culprit:

Article.findByPK(1);
lEntityManager.persist(lBatchcount);
Article.findByPK(2);


But it is not: the last find is done in the same connection as the first find.
However, this is happening because an entity does lazy loading (the setArticle fails):

lBatch.setArticle( batchtransferline.getArticle() );


Can it be that "batchtransferline", created outside the transaction, remembers which EM was used to create it?
So I moved the "emulate user" code inside the transaction and yes!

So the problem is that an entity uses the EM of the moment that is was created and not what is active at the time the lazy load is resolved!!!
Re: Brainflash: not so lazy / locking a record - EM remembering [message #385426 is a reply to message #385421] Mon, 02 February 2009 13:13 Go to previous messageGo to next message
Gordon Yorke is currently offline Gordon Yorke
Messages: 77
Registered: July 2009
Member
In the case of "lBatch.setArticle( batchtransferline.getArticle() );" the
"batchtransferline" must be detached with respect to the "active" EM.
(and by "active" I mean the one that is in use in your code as there may
be many EMs active at the same time) This means the EM and the
"batchtransferline" would have no idea that the other exists. You need to
have the "Article" loaded directly or through an Entity that is managed by
the "active" EM to ensure that the "active" EM is used to retrieve the
"Article".

Accessing the lazy references of a detached Entity is a non-spec feature
provided by EclipseLink. In other providers you would not have access to
the "batchtransferline.getArticle()" and would receive an exception
instead.

--Gordon
Re: Brainflash: not so lazy / locking a record - EM remembering [message #385427 is a reply to message #385426] Mon, 02 February 2009 15:51 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
> In the case of "lBatch.setArticle( batchtransferline.getArticle() );"
> the "batchtransferline" must be detached with respect to the "active"
> EM. (and by "active" I mean the one that is in use in your code as
> there may be many EMs active at the same time) This means the EM and the
> "batchtransferline" would have no idea that the other exists. You need
> to have the "Article" loaded directly or through an Entity that is
> managed by the "active" EM to ensure that the "active" EM is used to
> retrieve the "Article".

Well, not exactly; the post title should have said "connection remembering" and not "EM remembering". My bad.
If you would take a peek at my test code I added three posts back, you'll see that I create only one EM. The highlights:

....
EntityManager lEntityManager = BM.createEntityManager(lEntityManagerFactory);
....
Batchtransferline lBatchtransferline = new Batchtransferline();
lEntityManager.persist( lBatchtransferline );
lBatchtransferline.setArticle( Article.findByPK(82) );
....
lEntityManager.getTransaction().begin();
lBatchtransfer = lEntityManager.merge(lBatchtransfer);
lBatchtransferline.updateBatchcount(); // emulate application event "afterUpdate"
lEntityManager.getTransaction().commit();
....

The code around the new is run against connection 22221117, then the transaction begins and uses connection 18239702.
But the article that was fetched in the findByPK reuses connection 22221117 inside the transaction.

Tom
Re: Brainflash: not so lazy / locking a record - EM remembering [message #385428 is a reply to message #385427] Mon, 02 February 2009 21:35 Go to previous messageGo to next message
Gordon Yorke is currently offline Gordon Yorke
Messages: 77
Registered: July 2009
Member
So to be clear the EntityManager is created with the flag
"JOIN_EXISTING_TRANSACTION", you then "find" an Entity through this EM and
trigger the lazy relationship. Then you commit the transaction and you
have seen that a different connection is used for the find and lazy
loading than the transaction commit?
If this is the case then the behaviour is unexpected.
--Gordon
Re: Brainflash: not so lazy / locking a record - EM remembering [message #385429 is a reply to message #385428] Tue, 03 February 2009 01:22 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
Gordon Yorke wrote:
> So to be clear the EntityManager is created with the flag
> "JOIN_EXISTING_TRANSACTION", you then "find" an Entity through this EM
> and trigger the lazy relationship. Then you commit the transaction and
> you have seen that a different connection is used for the find and lazy
> loading than the transaction commit?
> If this is the case then the behaviour is unexpected.
> --Gordon
>

Yes.

EM made with JOIN_EXISTING_TRANSACTION (only one EM in the entire testcase).
find entity A before transaction uses connection I
transaction starts connection II
all actions are done using connection II
lazy load on entity A uses connection I (thus creating my lock conflict)
Re: Brainflash: not so lazy / locking a record - EM remembering [message #385431 is a reply to message #385429] Tue, 03 February 2009 09:48 Go to previous messageGo to next message
Gordon Yorke is currently offline Gordon Yorke
Messages: 77
Registered: July 2009
Member
Perform the find within the transaction. Finds outside the transaction
can not use the transactional connection.

The connection you are seeing is probably comming from loading of the
shared cache because the parent object was not loaded within the
transaction it will have been loaded into the cache. Triggering the
relationship will cause the relationship to be loaded into the cache as
well using a read connection. You could set the parent object to not use
a shared cache but the better approach is to read within the transaction.
--Gordon
Re: Brainflash: not so lazy / locking a record - EM remembering [message #385433 is a reply to message #385431] Tue, 03 February 2009 14:09 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
> Perform the find within the transaction. Finds outside the transaction
> can not use the transactional connection.

So far my whole application does not run inside a transaction, but only starts one when the user pressed "save" (note: we're talking about a fat client, 2-tier application).

I remember researching running inside or outside a transaction when I started to use Toplink, and found that when you do actions inside a transaction they are executed against the database immediately. That is not good from a locking perspective, since actions are related to user actions on the screen, so I chose the outside-transaction approach. (Which has worked perfectly so far.)


> The connection you are seeing is probably comming from loading of the
> shared cache because the parent object was not loaded within the
> transaction it will have been loaded into the cache. Triggering the
> relationship will cause the relationship to be loaded into the cache as
> well using a read connection. You could set the parent object to not
> use a shared cache but the better approach is to read within the
> transaction.

I'm running with cache disabled. I had a problem that objects weren't refreshed when I told them to. Since I have no advantage of the caching, I've disabled it.

cfg.put(PersistenceUnitProperties.CACHE_SHARED_DEFAULT, "false");

Still I think that when an EM has a certain connection active, especially with the join feature on, it should not start using other connections.

Tom
Re: Brainflash: not so lazy / locking a record - EM remembering [message #385434 is a reply to message #385433] Tue, 03 February 2009 15:15 Go to previous messageGo to next message
Gordon Yorke is currently offline Gordon Yorke
Messages: 77
Registered: July 2009
Member
If you are acquiring all EntityManagerFactories with
"PersistenceUnitProperties.CACHE_SHARED_DEFAULT, "false"" and you are
acquiring the EntityManager with "JOIN_EXISTING_TRANSACTION and then
triggering the lazy loading within an active transaction you should have
the relationship read through the same connection as the commit.

If you are not getting this behaviour please file a bug.
Re: Brainflash: not so lazy / locking a record - EM remembering [message #385435 is a reply to message #385434] Wed, 04 February 2009 04:42 Go to previous message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
Gordon Yorke wrote:
> If you are acquiring all EntityManagerFactories with
> "PersistenceUnitProperties.CACHE_SHARED_DEFAULT, "false"" and you are
> acquiring the EntityManager with "JOIN_EXISTING_TRANSACTION and then
> triggering the lazy loading within an active transaction you should have
> the relationship read through the same connection as the commit.
>
> If you are not getting this behaviour please file a bug.
>
>
>

I have fully denormalized my testcase, removed all my extentions and still get the wrong connection.

(Filed as Bug 263606)

System.out.println( "java.vm.version=" + System.getProperty("java.vm.version"));
com.informix.jdbc.Version.main(new String[]{});

// -------------

// entitymanagerfactory
Map<String, Object> cfg = new HashMap<String, Object>();
// always use ReindersInformixAndLoggingDriver so it hooks in the special informix connection class (which will automatically use the log4j driver)
cfg.put(PersistenceUnitProperties.JDBC_DRIVER, ReindersInformixAndLoggingDriver.class.getName()); cfg.put(PersistenceUnitProperties.JDBC_URL, ReindersInformixAndLoggingDriver.PREFIX + com.informix.jdbc.IfxDriver.class.getName() + "#" + " jdbc:informix-sqli://toeu_reinders:1527/reinders:INFORMIXSER VER=ol_ids10;DB_LOCALE=en_us.utf8");
cfg.put(PersistenceUnitProperties.JDBC_USER, "user"); cfg.put(PersistenceUnitProperties.JDBC_PASSWORD, "user"); cfg.put(PersistenceUnitProperties.TARGET_DATABASE, nl.reinders.jdbc.InformixPlatform.class.getName()); //until the extention is part of the jar: "Informix");
cfg.put(PersistenceUnitProperties.TARGET_SERVER, TargetServer.None);
cfg.put(PersistenceUnitProperties.WEAVING, "true");
cfg.put(PersistenceUnitProperties.JDBC_READ_CONNECTIONS_MIN, "0");
cfg.put(PersistenceUnitProperties.JDBC_READ_CONNECTIONS_MAX, "1");
cfg.put(PersistenceUnitProperties.JDBC_READ_CONNECTIONS_SHAR ED, "true");
cfg.put(PersistenceUnitProperties.JDBC_WRITE_CONNECTIONS_MIN , "0");
cfg.put(PersistenceUnitProperties.JDBC_WRITE_CONNECTIONS_MAX , "1");
cfg.put(PersistenceUnitProperties.CACHE_SHARED_DEFAULT, "false"); // do not use the shared cache (otherwise refresh will not update from db) cfg.put(PersistenceUnitProperties.LOGGING_EXCEPTIONS, "true");
final EntityManagerFactory lEntityManagerFactoryFinal = Persistence.createEntityManagerFactory("reinders", cfg);
EntityManagerFactory lEntityManagerFactory = (EntityManagerFactory) Proxy.newProxyInstance(BM.class.getClassLoader(), new Class[] { EntityManagerFactory.class }, new InvocationHandler()
{
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable
{
// invoke
Object lResult = method.invoke(lEntityManagerFactoryFinal, args);

// commit
if ("createEntityManager".equals(method.getName()) && lResult != null) {
((EntityManager)lResult).setFlushMode(FlushModeType.COMMIT);
}

// done
return lResult;
}
});

// entitymanager
Map<String, String> lOptions = new HashMap<String, String>();
lOptions.put(org.eclipse.persistence.config.EntityManagerPro perties.JOIN_EXISTING_TRANSACTION, "true");
EntityManager lEntityManager = lEntityManagerFactory.createEntityManager(lOptions);

// find article
Query lQuery = lEntityManager.createQuery("select t from Article t where t.iArticlenr=:articlenr");
lQuery.setParameter("articlenr", 82);
Article lArticle = (Article)lQuery.getSingleResult();

// transaction
lEntityManager.clear(); // prevent errors from a previous store session (not rollbacked optimistic lock increments) to screw things up
lEntityManager.getTransaction().begin();

// find another article
Query lQuery2 = lEntityManager.createQuery("select t from Article t where t.iArticlenr=:articlenr");
lQuery2.setParameter("articlenr", 143);
Article lArticle2 = (Article)lQuery.getSingleResult();

// now see what connections are used to lazy load
System.out.println("!!!!!!!!LAZYLOAD1");
new ArrayList(lArticle.getArticle2ArticlecatsWhereIAmArticle());
System.out.println("!!!!!!!!LAZYLOAD2");
new ArrayList(lArticle2.getArticle2ArticlecatsWhereIAmArticle()) ;

// and we're done
lEntityManager.getTransaction().commit();

// close shop
lEntityManager.close();
lEntityManagerFactory.close();


The log, ([C6815360] denotes the JDBC connection that is used):

java.vm.version=11.0-b12-fastdebug
IBM Informix JDBC Driver Version 3.50.JC3DE
[EL Info]: 2009.02.04 10:28:11.842--ServerSession(8303462)--EclipseLink, version: Eclipse Persistence Services - 1.0.2 (Build 20081024)
2009-02-04 10:28:12,483 DEBUG #16772849[C6815360]: executeUpdate( set lock mode to wait 30 ) returns #0: 0
2009-02-04 10:28:12,499 DEBUG #12742366[C6815360]: executeUpdate( set isolation to committed read ) returns #0: 0
2009-02-04 10:28:12,499 DEBUG #6942026[C6815360]: executeUpdate( set role javaapp1 ) returns #0: 0
[EL Info]: 2009.02.04 10:28:13.780--ServerSession(8303462)--file:/C:/Documents%20a nd%20Settings/user/My%20Documents/reinders/voorraad/containe r/bm/build/-reinders login successful
2009-02-04 10:28:14,967 DEBUG #13462176[C6815360]: [1] setBigDecimal=82 / java.math.BigDecimal / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-04 10:28:15,030 DEBUG #13462176[C6815360]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-04 10:28:15,202 DEBUG #30638763[C6815360]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-04 10:28:15,202 DEBUG #30638763[C6815360]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-04 10:28:15,296 DEBUG #10816932[C2056993]: executeUpdate( set lock mode to wait 30 ) returns #0: 0
2009-02-04 10:28:15,311 DEBUG #15312834[C2056993]: executeUpdate( set isolation to committed read ) returns #0: 0
2009-02-04 10:28:15,311 DEBUG #10265083[C2056993]: executeUpdate( set role javaapp1 ) returns #0: 0
2009-02-04 10:28:15,311 DEBUG org.tbee.util.jdbc.Connection.invoke(Connection.java:156) #2056993[C2056993]: setAutoCommit( false )
2009-02-04 10:28:15,311 DEBUG #9038937[C2056993]: executeUpdate( set constraints all deferred ) returns #0: 0
2009-02-04 10:28:15,311 DEBUG #9209226[C2056993]: [1] setBigDecimal=82 / java.math.BigDecimal / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-04 10:28:15,358 DEBUG #9209226[C2056993]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-04 10:28:15,374 DEBUG #23126121[C2056993]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-04 10:28:15,389 DEBUG #23126121[C2056993]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
!!!!!!!!LAZYLOAD1
2009-02-04 10:28:15,389 DEBUG #305514[C6815360]: [1] setInt=82 / java.lang.Integer / SELECT oidnr, articlenr, categorynr, lazylock, dwhmodified, dwhby FROM article2articlecat WHERE (articlenr = >>>HERE<<< )
2009-02-04 10:28:15,405 DEBUG #305514[C6815360]: executeQuery: SELECT oidnr, articlenr, categorynr, lazylock, dwhmodified, dwhby FROM article2articlecat WHERE (articlenr = ?)
2009-02-04 10:28:15,405 DEBUG #22129680[C6815360]: [1] setInt=82 / java.lang.Integer / SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = >>>HERE<<< )
2009-02-04 10:28:15,405 DEBUG #22129680[C6815360]: executeQuery: SELECT articlenr, articletypenr, description, sellingprice, length, width, inserted, std_reservation, haslicenses, minimalstock, is_landscape, actueel, weight, c, f, info, rolinstellingenok, rolkop, tapper, veer, lazylock, managestock, seqnr, keywords, opweb, dwhmodified, dwhby, ean, opwebdate, sale, trashcan, is_ending, artist, archive_location FROM article WHERE (articlenr = ?)
2009-02-04 10:28:15,436 DEBUG #15167987[C6815360]: [1] setInt=3 / java.lang.Integer / SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = >>>HERE<<< )
2009-02-04 10:28:15,452 DEBUG #15167987[C6815360]: executeQuery: SELECT articletypenr, code, description, dwhmodified, dwhby, lazylock, pricerulecode, grootboeknr FROM articletype WHERE (articletypenr = ?)
2009-02-04 10:28:15,467 DEBUG #20728841[C6815360]: [1] setInt=7 / java.lang.Integer / SELECT categorynr, description, lazylock, dwhmodified, dwhby FROM articlecat WHERE (categorynr = >>>HERE<<< )
2009-02-04 10:28:15,467 DEBUG #20728841[C6815360]: executeQuery: SELECT categorynr, description, lazylock, dwhmodified, dwhby FROM articlecat WHERE (categorynr = ?)
!!!!!!!!LAZYLOAD2
2009-02-04 10:28:15,467 DEBUG #3432913[C2056993]: [1] setInt=82 / java.lang.Integer / SELECT oidnr, articlenr, categorynr, lazylock, dwhmodified, dwhby FROM article2articlecat WHERE (articlenr = >>>HERE<<< )
2009-02-04 10:28:15,483 DEBUG #3432913[C2056993]: executeQuery: SELECT oidnr, articlenr, categorynr, lazylock, dwhmodified, dwhby FROM article2articlecat WHERE (articlenr = ?)
2009-02-04 10:28:15,483 DEBUG #27525999[C2056993]: [1] setInt=7 / java.lang.Integer / SELECT categorynr, description, lazylock, dwhmodified, dwhby FROM articlecat WHERE (categorynr = >>>HERE<<< )
2009-02-04 10:28:15,499 DEBUG #27525999[C2056993]: executeQuery: SELECT categorynr, description, lazylock, dwhmodified, dwhby FROM articlecat WHERE (categorynr = ?)
2009-02-04 10:28:15,655 DEBUG org.tbee.util.jdbc.Connection.invoke(Connection.java:156) #2056993[C2056993]: commit()
2009-02-04 10:28:15,655 DEBUG #12031745[C2056993]: executeUpdate( set constraints all deferred ) returns #0: 0
2009-02-04 10:28:15,655 DEBUG org.tbee.util.jdbc.Connection.invoke(Connection.java:156) #2056993[C2056993]: setAutoCommit( true )
[EL Info]: 2009.02.04 10:28:15.671--ServerSession(8303462)--file:/C:/Documents%20a nd%20Settings/user/My%20Documents/reinders/voorraad/containe r/bm/build/-reinders logout successful
Previous Topic:JPA: order by length?
Next Topic:EclipseLink at EclipseCon
Goto Forum:
  


Current Time: Thu Apr 24 01:30:15 EDT 2014

Powered by FUDForum. Page generated in 0.04012 seconds