fwiw, the architecture of the patch, allows for that use case, the zope transaction library defines a transaction manager, with apis for retrieving transaction objects and manipulating them and some convience items for commiting, aborting directly from the manager. data managers are objects that register with the transaction and recieve transaction messages, in a django context, a database connection wrapper would be a data manager. because the dbapi specifies transactions on a connection level, at implementation level, you'd need multiple database connections to achieve your goal of manipulation of db resources non transactionally while performing other ops transactionally, which would need additional support in django for multiple database connections, the other database connection wrapper for sessions, can simply not choose not to register with the transaction. in general though, as i mentioned before i think this sort of thing becomes extremely fragile outside of a specific app context, and the non transactional app behavior has to be carried over to any other app components using sessions. ie. if others are working with the same deployment they have to be aware of the details of the session usage as regards transactions. although i could definitely see storing sessions in as pickles in something like memcached but thats outside the txn framework entirely anyways, unless integration work is done.
-kapil
