Hi Andrus,
thanks for elaborating on this topic. The missing piece in the puzzle
was that the ObjectContext will request a connection from the DataSource
on demand. Having the ObjectContext independently available from the
transaction scope is another benefit for me.
Thanks for clearing this up, wish you guys a nice weekend!
Regards,
Daniel
Am 18.05.2012 09:14, schrieb Andrus Adamchik:
Hi Daniel,
If i understand correctly relationships are not necessary resolved directly but
lazy when accessed through an object.
Correct.
I mean obviously the object context is no longer valid (?) as potentially the
external transaction manager might have closed it's correspodning datasource
and returned it back to the connection pool.
Cayenne is not Hibernate. ObjectContext is not connected to DB and is always
"valid" until it goes out of scope.
My question now is how does the object context behave when it has to fetch some
additional objects due to relationships that have to be resolved on access?
ObjectContext will request a new connection from the DataSource. Whether it can
be granted at a given point or not depends on your app.
So again, unlike in Hibernate, you can keep your context around between multiple
transactions. All selects (direct, or when reading lazy relationships) as well as commits
result in connection request from a DataSource, so it has to be in a valid state (within
an open tx?) when that happens. After an operation is performed, Cayenne closes the
Connection and becomes "disconnected" again.
Does it clarify things a bit?
Andrus
On May 16, 2012, at 11:47 PM, Daniel Scheibe wrote:
Hi all,
i'm just in the process of creating a web application bound to cayenne in the
backend. I'm using external transactions (XA with multiple databases) and
basically start/commit/rollback a transaction whenever i have something to
change inside the databases. While this is working fine i'm trying to
understand the way cayenne behaves regarding the object context lifecycle.
Imagine the following use case:
startTX();
List<Object> objects = querySomeObjectsViaTheObjectContext();
commitTX(); or rollbackTX();
If i understand correctly relationships are not necessary resolved directly but
lazy when accessed through an object. My question now is how does the object
context behave when it has to fetch some additional objects due to
relationships that have to be resolved on access? I mean obviously the object
context is no longer valid (?) as potentially the external transaction manager
might have closed it's correspodning datasource and returned it back to the
connection pool.
However the objects in my list are still available in memory and can be used
although cannot be modified easily or be committed in the next transaction as
they of course don't belong to the newly created object context.
So what i'm doing right now (and i'm sure i'm missing some important facsts as
this is a really hack solution) is to create a new transaction, requery all the
objects i modified and transfer all modified attributes to the ones i just got
back from the query.
I'd really appreciate some explanation on how you guys approach stuff like, i
mean it's obvious that i have to store the objects in a user interface (showing
them in a table or whatever) but cannot keep and transaction ongoing as long as
the user interface is waiting for some interaction.
Cheers,
Daniel
