Skip to content

Commit

Permalink
Update instructions for controlling spatial index transactions
Browse files Browse the repository at this point in the history
  • Loading branch information
@mcpgovernance
mcpgovernance committed Aug 20, 2012
1 parent f52a2fe commit 6692428
Showing 1 changed file with 18 additions and 13 deletions.
31 changes: 18 additions & 13 deletions web/src/main/webapp/WEB-INF/config.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -358,22 +358,27 @@

<!-- The maximum number of writes in a transaction on the spatial index
Set to 1 forces the spatialIndexWriter to commit after each spatial
feature is written. Set to a large number and commits are delayed until
that number of spatial features is written. Be aware that setting this
number to anything other than 1 can cause problems if the connection
to the database is closed (eg. if the db admin shuts the database
for maintenance reasons). There are also performance implications that
are especially relevant to bulk loading records:
For the Apache Commons DBCP provider:
When using PostGIS on machines with fast/large pipe to disk, set
this number to 1 which means that the auto_commit transaction is
used. Also if having a long running transaction causes issues eg.
when database connections are reset by a firewall then set this
number to 1
Set this number to 1 for best performance. This is kind of counter
intuitive so if you have a different experience please pass it on as
a documentation fix.
For the JNDI database provider:
Set this number to something large eg. 1000 - setting this number
to 1 (=auto_commit) with a JNDI provider will cause database
connections involving the spatialindexwriter to be left open due
to what appears to be a bug in the GeoTools feature store when
using the auto_commit transaction. Curiously the
JNDI provider with maxWritesInTransaction set to 1000 is actually
faster to load and index records than ApacheDBCP provider
with PostgisDataStoreFactory and maxWritesInTransaction set to 1 -->
Set this number to something large eg. 1000 - the JNDI provider
is actually faster to load and index records with this setting than
if it is set to 1. This is what you would expect but you
may have problems that will require you to restart GeoNetwork and
reindex some or all of your metadata if the database connection is
interrupted.
-->
<param name="maxWritesInTransaction" value="1000" />

<param name="useSubversion" value="true"/>
Expand Down

3 comments on commit 6692428

@fxprunayre
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we set the default value to 1 as it will be better for DBCP (used probably most of the time) and will avoid the DB connection issue ?

@sppigot
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes - seems little point to leaving it at 1000 as that would possibly lead sites into trouble with DB connections. I was a bit hesitant to change it in 2.8 until spoken to you and other devs as must have time to test in 2.8 RC process - should be ok with RC1 and RC2 perhaps still to come?

@fxprunayre
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know a sequence of actions to trigger the error ? (stop/start the database when geonetwork is running with editing is not enough). I've changed the settings on the node I'm having the issue. I will keep you up to date if the problem occur again.

Please sign in to comment.