On Tue, Jun 27, 2000 at 08:04:50PM -0400, Nissim wrote:

> OK, Here are the issues that aren't resolved:

Good summary of the questions, here are my proposed answers.

> 1) Should the connection for the transaction be stored within BasePeer
> (through some sort of static Hashtable keyed on a transactionID) or
> through a new non abstract class?

Or we use the Connection object itself as the cookie that represents the
transaction. This seems the simplest, and John's changes to BasePeer are
a clear step towards this.

Then we can add some convenience methods to BasePeer like
beginTransaction(), commitTransaction() and rollbackTransaction(). 

As to the MySQL issue I would say a single supportsTransactions() in DB
should do the job. After all transactions are required in SQL-92
(allegedly) and MySQL 3.23 (now GPL :-) ) has them (again allegedly, I
haven't tried).

> 2) Should the check for whether transactions are needed (i.e. for
> postgres) be done within BasePeer, or in a higher level peer?

Okay, so when all the above is in place we can look at this Postgres
issue. It seems reasonable to have code to force a transaction if it is
actually *needed* as you've proposed in your patches. But this should
use a more general transaction mechanism like John's patches + the
above.

> 3) Should the check be:
>       a: Is it postgres
>       b: Check some method in the DB implementation (objectDataNeedsTrans)

Definitely (b) - I've given my reasons.

> 4) should we also check if there's a large object in the table, and only
> set up a transaction then , or always do transactions on postgresql?

I dunno - How bad is the overhead on just always doing the transaction -
it would certainly be easier and less intrusive on the code.

Otherwise some work is needed to restructure executeQuery so it has
knows whether any of the tables contain binary data. This should be
possible; although we'll need to change the signature of executeQuery -
does anyone actually use this method directly.

-- 
Sean Legassick
[EMAIL PROTECTED]


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?:           [EMAIL PROTECTED]

Reply via email to