> > Jody: > I think we should start some discussions about transaction handling. > Do you know this article > http://static.springframework.org/spring/docs/2.5.5/reference/transaction.ht > ml > Btw, GeoServer uses Spring, GeoServer should do the transaction handling, > not geotools (you know my opinion) > I share your opinion; but you are going to have to do some work to "teach" GeoTools how to interact with the external application. (ie design a solution and present it as a proposal). The existing interfaces are not going to meet your needs.
The original design documents are available; but perhaps a short email will suffice to get you started. Here is what the plan was ... - use a Repository to gather up all cross datastore operations; mostly locking and unlocking .. - The class Transaction was introduced to handle committing and rolling back several DataStores in one go. The name "Transaction" was chosen at the time; modern systems have the idea of a "Session" for the same idea ... - Transaction.State entries are used by the various DataStores to store some state that they care about for the duration of a session; it also acts as a callback object (so the state can be handled during commit() and rollback()). If you want a more complicated "Session" with two phase commit you will need to work on this interface and renegotiating the contract you have with DataStore implementors. Fine points of this plan are ... - Cross Datastore operations are handled by a Repository - Application provides a Repository; that way GeoTools can make use of facilities provided by the application - Given that Transaciton creation is a cross DataStore concern; the Repository should have a createTransaction() method - to create a Transaction that is happy for that environment (making use of application container facilities if that is what you need to do) That is where the plan has stalled; nobody has been interested in making anything other than the DefaultTransaction yet ... So I would recommend: - Making a new Transaction interface (perhaps called Session) that meets your needs. This can prove the concept and serve to motivate your design choices. - Repository idea seems dead ... replace with a SessionFactory Links: - http://docs.codehaus.org/display/GEOTDOC/Managing+DataStores+using+Repository+or+Catalog - http://udig.refractions.net/files/docs/api-geotools/org/geotools/data/Repository.html ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
