portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Müller (JIRA) <jetspeed-...@portals.apache.org>
Subject [jira] Commented: (JS2-666) Clustered Environment: constraint violation if clones are started at the same time
Date Fri, 14 Sep 2007 08:49:32 GMT

    [ 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


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.



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.) 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/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
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java(Compiled
> 	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

View raw message