The best source of docs is the WFS specification (it defines this "time based" locking idea).
You only need to do the feature locking when you have several threads working at once (it is not required if you just want to work on a transaction). I kind of thought you needed to add the authorization ( the one that was fetched using lockFeatures); prior to calling any featureWriter method. I also would only expect the authorization to last until a transaction using that authorization is committed(). The best thing to do is look at the datastore test cases where they try out the different locking strategies. Jody On Fri, Sep 3, 2010 at 2:58 AM, Yingqi Tang <[email protected]> wrote: > Hi, > > I'm just trying to understand how to use FeatureLock.TRANSACTION when > modifying features and committing changes. Here is a chunk of code I use: > > ...create data store for a PostGIS database... > ...get a JDBCDataStore... > ... > // create and set the default transaction > JDBCFeatureStore jdbcFeatureStore = > (JDBCFeatureStore)jdbcDataStore.getFeatureSource(typeName); > Transaction transaction = new DefaultTransaction(); > jdbcFeatureStore.setTransaction(transaction); > ... > // create and set lock > FeatureLock featureLock = FeatureLock.TRANSACTION; // use > FeatureLock.TRANSACTION > // FeatureLock featureLock = FeatureLockFactory.generate(60*60*1000); // > if I switch to use this lock, everything works fine like many cases in the > JUnit test > ... > jdbcFeatureStore.setFeatureLock(featureLock); > // add lock authorization to the transaction > transaction.addAuthorization(featureLock.getAuthorization()); > // lock features > jdbcFeatureStore.lockFeatures(); > // get writer > FeatureWriter<SimpleFeatureType, SimpleFeature> featureWriter = > jdbcDataStore.getFeatureWriter(typeName, transaction); > while(featureWriter.hasNext()) { > SimpleFeature simpleFeature = featureWriter.next(); > /*...change an attribute or something...*/ > featureWriter.write(); > } > // commit changes > try { > transaction.addAuthorization(featureLock.getAuthorization()); > > transaction.commit(); > // assume if it is FeatureLock.TRANSACTION lock then the lock should be > released automatically > } catch(Exception e) { > e.printStackTrace(); > transaction.rollback(); > } finally { > //transaction.addAuthorization(featureLock.getAuthorization()); > //jdbcFeatureStore.unLockFeatures(); > featureWriter.close(); > transaction.close(); > } > > with the code above, if I use a feature lock generated by > FeatureLockFactory.generate(60*60*1000), everything works fine, I can lock > features, modify, commit and finally unlock them. But as long as I switch to > use FeatureLock.TRANSACTION, there will be an exception saying things like > below: > > java.lang.IllegalMonitorStateException > at java.lang.Object.notifyAll(Native Method) > at > org.geotools.data.InProcessLockingManager$TransactionLock.release(InProcessLockingManager.java:634) > at > org.geotools.data.InProcessLockingManager$TransactionLock.commit(InProcessLockingManager.java:673) > at > org.geotools.data.DefaultTransaction.commit(DefaultTransaction.java:182) > at > org.geotools.playground.TestJDBCPostGIS.testWriteFeatures(TestJDBCPostGIS.java:325) > at > org.geotools.playground.TestJDBCPostGIS.main(TestJDBCPostGIS.java:435) > > Just wonder did I use FeatureLock.TRANSACTION correctly? If not, when and > how should I use it? I am able to find quite some good sample codes in JUnit > tests of jdbc module but they all seem to use the other lock. > > Thanks, > Yingqi > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Geotools-gt2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
