Thanks for the fun questions, answer in line. The features are visisble in the following rendering process *iff* the renderer is using the same Transaction (ie then it would use the same Transaction.State to hold the JDBC Connection, and thus would see the same data).
In uDig we carefully only allow the Rendering systems to grab FeatureSources that have been configured with a single Transaction per Map (so two maps can see data in different states of editing). The FeatureEvent model is aware of this and when you listen for events you have to provide a Transaction (so the system can be sure to deliver the correct sequence of events to you). So Transaction does provide *isolation*, if you do not want that (ie edit and view before commit) use the same Transaction. I like it when an API comes together like this :-) Jody Vitali Diatchkov wrote: > Hi, Jody. > > Here I see an issue related to rendering. > Each time rendering is performed features are requested from database again. > In ShapefileRenderer modified features are changed on-the-fly that are in > transaction state. > > In JDBC case if features are updated or inserted to the database but the > transaction is not committed yet, are they visible during following > rendering process? Or they are not accessible for renderers until > transaction will be committed? I suppose they are not visible until > transaction is committed... I modify the geometry of the feature, it is > updated in database, but the next rendering process draws the old state of > the feature until I actually commit GT transaction that forces committing of > database transaction.. > > Vitali. > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:geotools-devel- >> [EMAIL PROTECTED] On Behalf Of Jody Garnett >> Sent: Tuesday, August 29, 2006 6:07 PM >> To: Vitali Diatchkov >> Cc: geotools-devel@lists.sourceforge.net >> Subject: Re: [Geotools-devel] Transactions in geotools JDBC. >> >> Vitali Diatchkov wrote: >> >>> 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. >>> >>> >> The Transaction.State holds the JDBC connection, the transaction is >> implemented with SQL commit and rollback calls. For JDBC no in memory >> cache is needed. The TransactionStateDiff thing is only used by really >> simply things like shapefiles in order to bring them up to the level >> of WFS-T for the GeoServer application. >> >>> 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. >>> >>> >> Indeed, I would actually like to see a hsql based transaction state >> diff, so that shapefile is not memory bound even during a transaction. >> >>> 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. >>> >>> >> Um try out PostGIS to measure the performance, at the time it was 30 >> times faster then the previous approach (called "DataSource"). >> Cheers, >> Jody >> >> >> ------------------------------------------------------------------------- >> 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&kid0709&bid&3057&dat1642 >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > ------------------------------------------------------------------------- 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
