Since DataContext doesn't hold to a connection between DB calls,
DataContext.commitChanges() may or may not result in committing a DB
transaction (depending on whether transaction management configured as
internal or external). So good thing is that when writing persistence
code you don't care either way.
Now I guess when plugging external transaction management (when
integration with Spring and such), it maybe important to ensure that
the same connection is handed to all persistence operations within the
same external transaction (I guess that's the goal of the method
"executeTransaction", right?). A mechanism that binds a connection
object to the current thread, and then a connection pool wrapper that
hands it back to DataNode within the thread, may do the trick. Similar
to thread binding of DataContext that you implemented. All this is
external to Cayenne persistence code.
Does it make sense?
Andrus
On Jul 21, 2004, at 8:41 AM, Scott McClure wrote:
> In most Cayenne operations, you make the changes and then call
> commitChanges().
> In my application, this model is not working so well. In the Spring
> Hibernate
> code, there is a class that contains a callback in order to begin and
> end a
> session. Through this method, they have been very successful in
> creating more
> advanced features like declaritive transaction demarcation. The basic
> idea is
> to surround the request in a callback like this...
>
> API: DataContext.executeTransaction (Transaction)
>
> Code: dc.executeTransaction (new Transaction () {
> public Object execute () {
> //execute query, update some stuff...
> return results; //can be anything, a list, etc.
> }
> });
>
> Scott
This archive was generated by hypermail 2.0.0 : Wed Jul 21 2004 - 11:15:54 EDT