ORMFlush vs transaction

[David Sedeño]

Hi,

What is the difference between:

// Code 1:
obj1 = EntityLoadByPk('myclass', 1);
obj1.myvalue = 'hello';

obj2 = EntityLoadByPk('myclass', 2);
obj2.myvalue = 'bye';
ORMFlush();


// Code2 :
obj1 = EntityLoadByPk('myclass', 1);
obj1.myvalue = 'hello';

obj2 = EntityLoadByPk('myclass', 2);
transaction {
   obj2.myvalue = 'bye';
}

(both with flushatrequestend = false).

AFAIK, the two codes persist the both objects data to DB, so, what is the correct way or the difference between the two methods ?

Thanks
---
David Sedeño

[Nando Breiter]

Using a transaction will of course roll everything back, so if what you are doing with obj1 is related to what you are doing in obj2, as often would be the case in production code where obj1 is related to obj2, then wrap it all in a transaction, like so:

// Code2 :

transaction {

   obj1 = EntityLoadByPk('myclass', 1);
   obj1.myvalue = 'hello';

   obj2 = EntityLoadByPk('myclass', 2);
   obj2.myvalue = 'bye';

}

I've run into difficulty loading an object outside of a transaction and then persisting it within a transaction, as in your Code2. Hence my practice is to wrap an entire load, set, persist cycle in a single transaction, and usually I'll include commit and rollback statements within it so that I can better handle the cases where I might want to do either. 

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your ticket NOW - http://www.cfcamp.org/
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ba5d0093-4bdc-446b-a77c-a193fa42b263%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Sedeño]

Hi Nando,

Yes, there was a problem in Lucee with persistent of object in transaction, but this bug is fixed in vers. 4.5.1.022.

The code works as expected in that version, no need to put all the code in inside transaction {}.

Cheers

You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/-48irM146Bc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGHrs%3D9zMcBp-rn_E3vxZq8r9zOZORQUDR%3DtKhMhyNRxAjLcvg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

David Sedeño Fernández

Zoconet SL

david....@todocoleccion.net

Tel. 657 384 329

[Nando Breiter]

Well, does an empty transaction work?

// Code3 :

obj1 = EntityLoadByPk('myclass', 1);
obj1.myvalue = 'hello';

obj2 = EntityLoadByPk('myclass', 2);

obj2.myvalue = 'bye';
transaction {
   
}

Logically, it seems like it might if your Code2 example also persists obj1. 

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAPJegvrEr3jGmUftHjb%2BWHdy4%2BpvVx7HPAz9DH1ZsWVC%3DS7Jpg%40mail.gmail.com.

[David Sedeño]

No, an empty transaction not work, you must put at least one object change within transaction {} that will persist all objects to DB.

With an ORMFlush without transaction is similar. So my question is, is there any differenct between both method?

Cheers

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGHrs%3D-XV9OiO2rGo0yJZwRnw-mKmeDE5oTAPqGvS-KpV2JPPg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Nando Breiter]

Well again, the obvious difference should be that if there is an error during persistence, a transaction will roll everything contained within it back to its original state. ORMFlush() would allow the portions that have been persisted before the error to remain. At least that's the theory.

Accordingly, I would have expected obj1.myvalue = 'hello'; in your Code2 to not have been persisted, but it seems my expectation isn't correct.

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAPJegvpxk1qytS5CxU%2BtUiby5piEWE4CbwJuMmxjtuSH93XCOA%40mail.gmail.com.

[Luis Majano]

David,

There are some considerable differences between them.

The first approach just leverages the ORMFlush() method to send everything that is contained in the Hibernate Session to the Database. This will send all the queued SQL statements in order to synchronize the objects with the persistence layer.  That's it.  If there are any exceptions along the way, partial data will be in the DB and partial data will be inconsistent. This can created undesirable data integrity issues and inconsistencies.

The transaction approach is what I would say the preferred approach as it creates a demarcation boundary around the proposed work to send as a unit to the database.  This means that you are creating a unit of work that if it executes it should be persisted, thus flushed into the db.  If there are any exceptions along the unit of work, the unit should NOT commit to the database and have inconsistencies.

Transactions will inherently take care of the flush for you, but also roll back if necessary and manage the closing, opening, flushing and clearing of the underlying hibernate session.