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 >
