Estoy usando OpenJPA y tengo un problema de bloqueo. Ya entiendo qué es una OptimisticLockException y cuándo se lanza.

¿Pero cómo puedo lidiar con eso?

A continuación *, puede encontrar un pequeño párrafo sobre las excepciones optimistas de bloqueo.

n pocas palabras, ¿cómo puedo desactivar totalmente el administrador de bloqueos?

En mi persistent.xml, tengo el siguiente código xml pero no funciona. Por qué

...
<properties>
  <property name="openjpa.LockManager" value="none" />
</properties>
...

* Según los wikilibros sobre Java Persistent:

Manejando excepciones optimistas de bloqueo

Lamentablemente, los programadores con frecuencia pueden ser demasiado inteligentes para su propio bien. El primer problema que surge cuando se utiliza el bloqueo optimista es qué hacer cuando se produce una OptimisticLockException. La respuesta típica del amigable súper programador del vecindario es manejar automáticamente la excepción. Simplemente crearán una nueva transacción, actualizarán el objeto para restablecer su versión y fusionarán los datos nuevamente en el objeto y lo volverán a confirmar. Problema presto resuelto, ¿o sí?

Esto en realidad derrota todo el punto de bloqueo en primer lugar. Si esto es lo que desea, también puede usar sin bloqueo. Desafortunadamente, la OptimisticLockException rara vez se debe manejar automáticamente, y realmente necesita molestar al usuario sobre el problema. Debe informar el conflicto al usuario y decir "lo siento, pero ocurrió un conflicto de edición y tendrán que rehacer su trabajo" o, en el mejor de los casos, actualizar el objeto y presentar al usuario los datos actuales y los datos que presentaron y ayudarlos a fusionar los dos, si corresponde.

Algunas herramientas de fusión automatizadas compararán las dos versiones en conflicto de los datos y, si ninguno de los campos individuales entra en conflicto, los datos se fusionarán automáticamente sin la ayuda del usuario. Esto es lo que hacen la mayoría de los sistemas de control de versiones de software. Desafortunadamente, el usuario generalmente es más capaz de decidir cuándo algo es un conflicto que el programa, solo porque dos versiones del archivo .java no cambiaron la misma línea de código no significa que no hubo conflicto, el primer usuario podría haber eliminado un método al que el otro usuario agregó un método de referencia, y varios otros posibles problemas que hacen que la compilación típicamente nocturna se rompa de vez en cuando.