> >
> > If I understand you correctly, the problem with this is that it
> > introduces the overhead of a transaction when reading/writing the object
> > data column for *any* database that supports transactions, not just
> > Postgres. This seems undesirable to me.
> >
>
> Are you both saying that BasePeer should remain as it is in the last
> patch I submitted, with transactions, but with no special code for large
> object support? Then the large object hack should go in the higher level
> peer class, but use a method on the db which says hasTransactions()?
Or use a more specific adaptor method, I'm only -0 on it, and could easily
be changed if someone told me the transaction is significant overhead. (I
have not needed to use transactions before, I do not have experience with
them at all, let alone the variations among db's.)
> Also, I call your attintion to the fact that there already is database
> specific code in the TurbineUserPeer:
>
> 168 if (
> TurbineResources.getString("database.default.driver", "" )
> 169 .startsWith("oracle") )
> 170 {
> 171 id = getNextId(SEQUENCE_NAME);
> 172 criteria.add(VISITOR_ID, id);
> 173 BasePeer.doInsert(criteria);
> 174 }
>
> If that's OK, we can also put code in there which calls the transaction
> methods if:
>
> TurbineResources.getString("database.default.driver", "" )
> .startsWith("org.postgres")
>
I guess I shouldn't -1 this, since I am the one that put the other statement
in there. But please come up with a better solution. I have experience
with oracle and mysql. I do not know how easy it is to generalize the
sequence method of generating primary keys.
IDBroker is an attempt to get away from the many different ways of doing
this, but not all the problems with it have been worked out. One that I do
not think can be overcome is in an application that is integrating with
other systems at the database level. For applications that do not have this
baggage and are looking for db independence, I think that IDBroker is a good
solution.
The only other problem I see with IDBroker is it is not currently safe for
multiple jvms. One solution Frank was considering was using RMI. I do not
think he implemented it, and it may not be the best way to go. If objects
are needing to use RMI to get a key, it may be hard to see the advantage in
db independence, with the well optimized db-dependent sequence methods being
available.
I am thinking that with the transaction support being added, it may be
possible to get IDBroker to be multiple jvm safe (if you are using a db that
supports transactions). The additional transaction overhead can be offset
by the ability to tailor the number of keys retrieved to the load. There
are still probably db dependent methods that still have an efficiency
advantage here, but I think they lose their appeal since IDBroker can be set
up to compensate for demand.
Thoughts?
Other than that I would say your solutions appears right on track. You
don't have to wait for my tangential issue to get worked out.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
