David Soergel wrote:
> How funny, I just made a similar change a couple of days ago (just
> locally). What I did was to give DataSet and ExecuteStatement a
> reference to a DBConnection object, instead of extending the class.
> That way, a given set of connection parameters is represented by a
> single DBConnection, which you can then pass in to TableDataSet etc.
> It sounds like you did exactly the same thing, but took it further.
> Cool :)
>
> The reason I needed to do that was that I've been working on
> transaction support. It's almost done, I think, and just testing it
> some more before checking it in.
>
> Here's how it works: I added a Transaction class, which takes a
> DBConnection (or, soon, a ConnDefinition) argument to the
> constructor. The constructor grabs a Connection, turns autocommit
> off, and holds it. You can then pass this Transaction around to
> Record.save() and other relevant methods. Transaction.commit() and
> rollback() then do the obvious, turn autocommit on again, and return
> the connection to the pool.
>
> I added transactional versions of methods that update the database,
> but not of select methods in Table, because of concerns that the
> local cache can get out of sync with the database. My solution is to
> put a lock on Records while they are being modified in memory; the
> lock then gets removed on commit. In the case of rollback, the
> cached version of the object gets tossed since it might be dirty.
> Thus, Table's cache will always reflect the most recent committed
> state of the database. This mechanism does not support cases where a
> select depends on an update that happened before it in the same
> transaction (since that would require multiple copies in memory of
> the same database row, which is just what I've been trying to avoid).
Sounds great David... transaction support would be nice. As we start
adding more robust features, I was wondering how and what should be
thread safe in Town. The connection pools are thread safe, and I have
no idea about the Table object or any of the OR stuff, but I know
TableDataSet and QueryDataSet and generally not thread safe. Is this
something we want to change? Or is it safe to assume that only 1 thread
will use a TableDataSet at a time?
One thing on the OR mapping... I think I forgot to update some of the
java code generation stuff to work with the new API... hopefully I got
it, but just a warning. I don't have anything to test that
functionality, so if you uncover anything, hopefully it's easy fixes.
Serge Knystautas
Loki Technologies
http://www.lokitech.com
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
