Achtung!:) The question is about transactions in geotools JDBC API.
ShapefileDataStore and ShapefileRenderer are working against transaction state in memory. Modified/added/removed features are kept in transaction state in memory until we commit to rewrite shapefile or rollback modifications. What is a desired design in JDBC case? I see that the performance would depend on use case. Whether each time the user modifies feature it is updated in database's transaction or in-memory cache of changed features is preferable solution like in ShapefileDataStore case? In-memory cache I mean like using ShapefileDataStore and its in-memory transaction state. During rendering modified features from external data store are changed by features being in transaction state on-the-fly. When we commit transaction - we rewrite shapefile with all modifications. What if each time I modify a feature a request to database is performed.. What would be a performance of this "external transaction" approach using database's transaction capabilities - when all changes are performed using INSERT/DELETE/UPDATE operations whenever any change is detected but the database transaction is able to commit or rollback them. Vitali. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
