[jira] Commented: (JS2-666) Clustered Environment: constraint violation if clones are started at the same time

["Joachim Müller (JIRA)" <je...@portals.apache.org>]

    [ https://issues.apache.org/jira/browse/JS2-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527410 ] 

Joachim Müller commented on JS2-666:
------------------------------------

The problem here is that the (re)registering defined in

PortletApplicationManager.registerPortletApplication(...)

is not encapsulated in one and only one transaction and the transactions are not blocking other clusters. To change the data of the PortletApplication it uses methods of the PersistenceBrokerPortletRegistry which are encapsulated by transactions for removing and creating a portlet application.

i.e.

PersistenceBrokerPortletRegistry.registerPortletApplication(PortletApplicationDefinition)
PersistenceBrokerPortletRegistry.removeApplication(PortletApplicationDefinition)


Since (re)registering removes and inserts data from the database which is not fully encapsulated by one transaction and not write locked, there maybe conflicts. A sample:

A = cluster node 1
B = cluster node 2

- A removes PA from DB
- B removes PA from DB again (with no effect)
- A inserts PA into DB
- B inserts PA into DB (exists with duplicat key constraints violation)


What would be the options:

1.) Make sure only one cluster node can (re)deploy the portlet application at once.

A first approach could be be:
- delete and insert should only be executed, if not executed yet by another cluster node
- to synchronize add a kind of "monitor" to the database (e.g. new table with monitoring "flag" and optimistic locking)
- every cluster node checks the monitor
- if monitor not set, the cluster node sets it and executes the deletion/insert stuff
- if monitor set, the cluster node waits until monitor is "free" and only reloads the registry (with the already written Portlet Application by the other cluster node)
- if both cluster nodes want to update the monitor, optimistic locking leads to an exception on one side. that side then also should wait and reload
- make sure the cluster node retries to (re)deploy the portlet application on exception (see 2.))


2.) Catch the exception, roll back and keep on trying to (re)deploy the porlet.xml

I am not sure if this is a good solution because multiple transactions on multiple cluster nodes could produce invalid data in the database tables or deadlocks? (I am not an clustered eviroment database expert ;-))

3.) change the (re) deploy process:

- avoid deletion of the portlet application
- step trough the object tree and insert/update only if necessary
- combine this with optimistic locking (requires data model change)

4.) another slick solution that makes everything much easier :-) (maybe at OJB level?) 


I would like to synchronize with the core developers before starting to implement a solution. What do you think? 

The quickest solution for now with the least impact on data model and code base would be 2.), but I am not sure if this is a really robust solution. Please comment.


To generally avoid problems in clustered environments we maybe have to change some aspects of the database access via OJB as stated in :

http://db.apache.org/ojb/docu/howtos/howto-work-with-clustering.html
http://db.apache.org/ojb/docu/guides/lockmanager.html#LockManagerRemoteImpl (?)


> Clustered Environment: constraint violation if clones are started at the same time
> ----------------------------------------------------------------------------------
>
>                 Key: JS2-666
>                 URL: https://issues.apache.org/jira/browse/JS2-666
>             Project: Jetspeed 2
>          Issue Type: Bug
>          Components: Portlet Registry
>    Affects Versions: 2.1
>         Environment: Websphere Application Server 6.0
> Database DB2 8.2
>            Reporter: Frank Stalherm
>             Fix For: 2.2
>
>
> Clustered Environment: constraint violation if clones are started at the same time.
> Exception thrown:
> com.ibm.websphere.ce.cm.DuplicateKeyException: [IBM][CLI Driver][DB2/6000] SQL0803N  One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "2" constrains table "PORTLET_APPLICATION" from having duplicate rows for those columns.  SQLSTATE=23505
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java(Compiled Code))
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java(Compiled Code))
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java(Compiled Code))
> 	at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapExceptionHelper(GenericDataStoreHelper.java:502)
> 	at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapException(GenericDataStoreHelper.java:545)
> 	at com.ibm.ws.rsadapter.jdbc.WSJdbcUtil.mapException(WSJdbcUtil.java:902)
> 	at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.executeUpdate(WSJdbcPreparedStatement.java:555)
> 	at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:216)
> 	at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1754)
> 	at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:813)
> 	at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:726)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org