Jody,
Now I put the code in a multi-threads scenario to justify the
locking/unlocking workflow, below is the sample code:
for(int i=0; i<4; i++) {
// spread a new thread
final String id = String.valueOf(i);
threadPool.execute(
new Runnable() {
public void run() {
try {
String targetFeatureTypeName =
"sf_pizzastores_wgs84";
JDBCFeatureStore jdbcFeatureStore =
(JDBCFeatureStore)jdbcDataStore.getFeatureSource(targetFeatureTypeName);
Transaction transaction = new
DefaultTransaction();
FeatureLock featureLock =
FeatureLockFactory.generate("lock_"+id, 60*60*1000);
String lockId = featureLock.getAuthorization();
jdbcFeatureStore.setTransaction(transaction);
jdbcFeatureStore.setFeatureLock(featureLock);
transaction.addAuthorization(lockId);
FeatureWriter<SimpleFeatureType, SimpleFeature>
featureWriter = jdbcDataStore.getFeatureWriter(targetFeatureTypeName,
transaction);
jdbcFeatureStore.lockFeatures();
while(featureWriter.hasNext()) {
SimpleFeature simpleFeature =
featureWriter.next();
String store_id =
(String)simpleFeature.getAttribute("store_id");
simpleFeature.setAttribute("name", "ps"+ id
+ "." + store_id);
transaction.addAuthorization(lockId);
featureWriter.write();
}
try {
transaction.addAuthorization(lockId);
transaction.commit();
} catch(Exception e) {
transaction.rollback();
e.printStackTrace();
} finally {
transaction.addAuthorization(lockId);
jdbcFeatureStore.unLockFeatures();
featureWriter.close();
transaction.close();
}
} catch(Exception e) {
e.printStackTrace();
} finally {
}
}
}
);
}
threadPool.shutdown();
Basically I start 4 identical threads concurrently, and in each of those I
do following things:
create a DefaultTransaction() and a FeatureLock;
Lock all the features in the table
Modify an attribute value in each feature
Commit the edits
Unlock all features
I'm expecting to see that only one of the thread will go through the process
and commit the change back to database, while the rest 3 threads will be
locked out. But when I run it I'm seeing most of time all 4 threads fail to
write() features and complaining about transaction doesn't have the
authorization.
Just wonder if this is a valid test case I created, I went through the test
code and all of them are single thread based which will also work fine for
me. Do you know any multi-thread example.
Another thing is that using FeatureLock.TRANSACTION still doesn't work for
me. Whenever I use it in the code above to replace the regular lock I'm
getting java.lang.IllegalMonitorStateException exception when it's trying to
release the lock by calling notifyAll().
Any input will be really helpful!!!
Thanks
On Thu, Sep 2, 2010 at 8:31 PM, Jody Garnett <[email protected]> wrote:
> 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
