Paul,
I might argue that actual locking login should not be part of
GeoServer proper, but part of the data source layer. That way data
sources which support long transactions natively (Oracle9i and
ArcSDE/GeoDatabase, for example) can implement it properly.
This is a good point, but this would mean essentially pushing the
locking functionality into GeoTools, since this is where the data
sources live. This may or may not be a good thing. I will think about
this. As for in-memory locking models, I definitely agree, I was just
thinking of XML for serialization, which may even be overkill
OK, so I am of two (three) minds. Having GeoServer handle locking
'automagically' simplifies design a good deal. However you
are going to have alot of hard design issues keeping your locking
cache ACID which
would be much more easily avoided by using an RDBMS to store
the info. And of course handling it yourself means you might not get
to
use more elegant long transaction features of the more elabourate
RDBMSs.
I am thinking of a much simpler model in the short term that locks
entire data sets for data sources without native transactional locking.
I fear the complications of feature-level ACID transactional support, so
I am just attempting to keep it as simple as possible for now. Plus,
those who will use flat files (like .SHP) for their data storage needs
probably aren't anticipating zillions of users concurrently modifying
them anyway, so I am think that getting extremely sophisticated in
supporting them might be overkill.
On a parallel track, have you thought about the file
integrity issues
which adhere to giving write access to file-based data sources? Paul
Not much. This is handled in the datasources and is all quite primitive
at this point. I am focusing on transactional PostGIS support, then
worrying about this stuff. This is a really helpful
conversation...appreciate your thoughts on the subject. Hopefully, it
is also giving you guidance as to where effort could be spent usefully
to help out improving the server!
The opportunity for clobbering and dirty reads without a
transactional mechanism is legion. ESRI is well aware that long
transaction
support is going to be key to GIS over the next 10 years and are being
very
proactive in supporting it. We should be as clever.
I completely agree and my lack of thought is only due to my focus on
simpler things like adhering to the spec request and response syntax,
first. If I were smarter and better, GeoServer would have a more
developed master plan for locking mechanisms, but the project is just
not quite there, yet. This the main reason I am attempting to simplify
the problem.
Rob