I spent the morning looking this over and I think it looks great. I like
setCurrentLock operation as a way to provide short or long transactions.
GeoServer probably won't use it, but it makes good sense to provide it for
geotools, as users could desire that sort of locking, as for many it makes
more sense than the lockId long transaction style. And the locking table
in postgis definitely seems the way to go. I thought of something like
this when I was looking for initial solutions to the locking problem, but
yours is far more elegant than anything I came up with.
One question I do have is about the
AbstractTransactionalDatasource - is it going to be JDBC based or not?
You can obviously reduce a lot of code duplication if you do that, as you
can probably handle most of the connection handling there. But if you do
that we should figure out if it will ever be possible to have file based
datasources be transactional. Obviously that functionaliy will be hacked
in, as files don't lend themselves naturally to transaction operations.
The notion has been kicked around in geotools for a bit, at least
implementing add, modify and remove in shapefile by having some sort of
transaction recorder that holds the modified features in memory until
commit() is called, at which point setFeatures() would be called. I
suppose a locking similar to GeoServer could be implemented there as well.
If done correctly I could see an AbstractFileTransactionalDatasource that
could handle add, remove and modify operations, as well as commit/rollback
and perhaps even locking if the file datasources were to just implement
setFeatures. The overlap in code between FileTransactionalDatasource and
JDBCTransactionalDatasource would probably be fairly minimal. This
obviously does not have to be figured out right now, but if you are
planning on common jdbc code in abstractTransDS, then you might consider
renaming to rbdmDataSource or something to indicate that file based
datasources can't extend it. But we can also just cross that bridge when
someone actually tries to make shapefile transactional.
As for your note about addFeatures() with locking, we should ask
the spec author. I could see that if the whole datasource was locked then
an insert should not be allowed, but we should find out for sure first, as
implementing it only has the one purpose. But yes, the javadocs look
great, I'm excited to see it coded up.
Chris
On Fri, 25 Jul 2003, Jody Garnett wrote:
Attached are java docs for extending the DataSource API to handle locking.
Please have a look at the attached files, as I would love some feedback
before coding next week.
To recap:
- the goal is to provide strong transaction support for geoserver (use
the database rather than just geoserver)
- using per row locking, while easy to implement for geotools2, does not
meet the locking requirements for geoserver
The API proposed:
- and can be implement in Postgis.
- can be implemented in geotools2 by porting geoservers locking code
over to an AbstractTransactionalDatasource
After getting this up and going for Postgis I will be working on
providing support for OracleSpatial and ArcSDE.
Thanks,
Jody Garnett
Example Use: TypeRepository.addToLock
List fids = getFidFeatures(typeName, filter);
DataSource ds = dataSourceByName(typeName);
Lock lock = Lock.create(1800);
if ( lockAll && ds instanceof TransactionalDataSource ){
TransactionalDataSource tds = (TransactionalDataSource) ds;
try {
tds.setCurrentLock(locky);
tds.lock(filter);
tds.commit();
} catch (DataSourceException e) {
throw new WfsException(e);
}
}
InternalLock internallock = (InternalLock)locks.get( lock.getID() );
internallock.addFeatures(lockAll, getFidFeatures(typeName, filter));