关于Oracle adf 报Thread: JBO-25014: Another user has changed the row with primary key oracle.jbo.Key
2011-10-17 20:00
891 查看
PS:本文我又补了个译文
网上的解决方案:
The oracle.jbo.RowInconsistentException is the BC4J framework's way of telling you that another user has changed the row since your current user initially queried it. This is an important feature to avoid against the so-called "Lost Update Problem" if two
users try to modify the same row in sequence. Depending on whether you are using pessimistic or optimistic locking, you may see the error as soon as you attempt to modify any attribute of an entity object with pessimistic locking or you may see it during the
post/commit processing for optimistic locking. Our locking mode defaults to pessimistic, and can be set globally by providing a value like optimistic for the jbo.locking.mode configuration property in the configuration for the application module that you use
as the root application module for your application.
You can use the BC4J tester (by picking the "Test..." option from the right-mouse menu on your application module) to simulate the situation in which this error will occur. Just launch two separate testers by selecting "Test..." twice. With two instances of
the BC4J tester running, query up the same row in both and then make a modification to some attribute in that row using one of the tester windows, followed by commit. When you try in the 2nd tester window to modify an attribute in that same row, you'll get
the oracle.jbo.RowInconsistentException raised -- immediately if you leave the default pessimistic locking mode, or at commit time with jbo.locking.mode=optimistic in your configuration.
If your BC4J/ADF-based application is getting the this exception, then one of two things is going on:
Another user really has updated the row since your current user retrieved it
Your application may contain a problem that makes BC4J think that the row has been changed when logically no other user has really changed it.
After understanding how we detect that the row has changed, we'll look at a couple of reasons this error might occur unintentionally.
When we go to lock a row for update, against Oracle we issue a SQL statement like this:
SELECT <list of all columns to which your entity object's persistent attributes are mapped>
FROM <table name that your entity object is mapped to>
WHERE <primary key columns = current values of corresponding PK attributes of entity>
FOR UPDATE NOWAIT
If we succeed in locking the row, the we have in our hot little hands the values of all the persistent attributes in your entity object instance that we just selected during the lock attempt. These represent the most current state of the committed database
values for the attributes.
If you do not have any attribute marked as a "Change Indicator" attribute -- in which case we would only compare the value of that single change indicator attribute -- then we compare the just-selected-during-the-lock values with the values of attributes that
we have in the entity object as they existed at the time you selected them originally. These "original values" are the same values that are available to you as the Entity Object developer using the getPostedAttribute() API. If any of the just-selected-during-the-lock
attribute values differs from the original values of the current entity object instance, the RowInconsistentException is thrown.
Five common reasons for which this error can be thrown when logically you believe it should not, are:
You have database triggers modifying the values of some of the columns on which your entity's persistent attributes are based, and you have failed to correctly indicate that to BC4J with the "Refresh on Insert" and/or "Refresh on Update" flags on the entity
object attribute definition.
You have (or have added) database level column default values for attributes and failed to correctly indicate that to BC4J with the "Refresh on Insert" property for the corresponding attribute.
You have created a view object with "Expert Mode" custom SQL statement, and have gotten the SELECT list of your custom SQL statement out of sync with the view object attributes.
You are using an attribute whose type is a custom domain class and have failed to correctly implement the equals() method for your custom domain class.
Your are using a ROWID-valued attribute in your entity and have not marked it to "Refresh on Insert" and "Refresh on Update". Some features of the database like partitioning can cause the value of ROWID to be updated when data in the row is updated.
In the first and second cases, set the refresh flags appropriately for any related entity object attributes that your triggers are changing.
In the third case, double-check that your custom SQL statement is not accidentally selecting the value of the wrong column inadvertently into your view object attributes, and visit the "Attribute Mappings" panel to verify that the select-list to view object
attribute mappings are as they should be.
In the fourth case, BC4J relies on your domain class' being able to compare itself properly with another instance of the same class, so you'll need to implement a correctly-functioning equals() method for your custom domain class.
In the fifth case, just mark the indicated attribute flags to avoid the problem.
网上的解决方案:
The oracle.jbo.RowInconsistentException is the BC4J framework's way of telling you that another user has changed the row since your current user initially queried it. This is an important feature to avoid against the so-called "Lost Update Problem" if two
users try to modify the same row in sequence. Depending on whether you are using pessimistic or optimistic locking, you may see the error as soon as you attempt to modify any attribute of an entity object with pessimistic locking or you may see it during the
post/commit processing for optimistic locking. Our locking mode defaults to pessimistic, and can be set globally by providing a value like optimistic for the jbo.locking.mode configuration property in the configuration for the application module that you use
as the root application module for your application.
You can use the BC4J tester (by picking the "Test..." option from the right-mouse menu on your application module) to simulate the situation in which this error will occur. Just launch two separate testers by selecting "Test..." twice. With two instances of
the BC4J tester running, query up the same row in both and then make a modification to some attribute in that row using one of the tester windows, followed by commit. When you try in the 2nd tester window to modify an attribute in that same row, you'll get
the oracle.jbo.RowInconsistentException raised -- immediately if you leave the default pessimistic locking mode, or at commit time with jbo.locking.mode=optimistic in your configuration.
If your BC4J/ADF-based application is getting the this exception, then one of two things is going on:
Another user really has updated the row since your current user retrieved it
Your application may contain a problem that makes BC4J think that the row has been changed when logically no other user has really changed it.
After understanding how we detect that the row has changed, we'll look at a couple of reasons this error might occur unintentionally.
When we go to lock a row for update, against Oracle we issue a SQL statement like this:
SELECT <list of all columns to which your entity object's persistent attributes are mapped>
FROM <table name that your entity object is mapped to>
WHERE <primary key columns = current values of corresponding PK attributes of entity>
FOR UPDATE NOWAIT
If we succeed in locking the row, the we have in our hot little hands the values of all the persistent attributes in your entity object instance that we just selected during the lock attempt. These represent the most current state of the committed database
values for the attributes.
If you do not have any attribute marked as a "Change Indicator" attribute -- in which case we would only compare the value of that single change indicator attribute -- then we compare the just-selected-during-the-lock values with the values of attributes that
we have in the entity object as they existed at the time you selected them originally. These "original values" are the same values that are available to you as the Entity Object developer using the getPostedAttribute() API. If any of the just-selected-during-the-lock
attribute values differs from the original values of the current entity object instance, the RowInconsistentException is thrown.
Five common reasons for which this error can be thrown when logically you believe it should not, are:
You have database triggers modifying the values of some of the columns on which your entity's persistent attributes are based, and you have failed to correctly indicate that to BC4J with the "Refresh on Insert" and/or "Refresh on Update" flags on the entity
object attribute definition.
You have (or have added) database level column default values for attributes and failed to correctly indicate that to BC4J with the "Refresh on Insert" property for the corresponding attribute.
You have created a view object with "Expert Mode" custom SQL statement, and have gotten the SELECT list of your custom SQL statement out of sync with the view object attributes.
You are using an attribute whose type is a custom domain class and have failed to correctly implement the equals() method for your custom domain class.
Your are using a ROWID-valued attribute in your entity and have not marked it to "Refresh on Insert" and "Refresh on Update". Some features of the database like partitioning can cause the value of ROWID to be updated when data in the row is updated.
In the first and second cases, set the refresh flags appropriately for any related entity object attributes that your triggers are changing.
In the third case, double-check that your custom SQL statement is not accidentally selecting the value of the wrong column inadvertently into your view object attributes, and visit the "Attribute Mappings" panel to verify that the select-list to view object
attribute mappings are as they should be.
In the fourth case, BC4J relies on your domain class' being able to compare itself properly with another instance of the same class, so you'll need to implement a correctly-functioning equals() method for your custom domain class.
In the fifth case, just mark the indicated attribute flags to avoid the problem.
相关文章推荐
- 关于Oracle adf 报Thread: JBO-25014: Another user has changed the row with primary key oracle.jbo.Key
- oracle.jbo.RowInconsistentException: JBO-25014: Another user has changed the row with primary key or
- JBO-25014: Another user has changed the row with primary key oracle.jbo.Key[x]
- 关于The web application [/cdmaPlus] created a ThreadLocal with key of type
- ASP.NET MVC another entity of the same type already has the same primary key value
- 关于run-time error:The thread has exited with code :1073741701 (0xc000007b)
- 关于Adapter的The content of the adapter has changed but ListView did not receive a notification.问题分析
- 错误:created a ThreadLocal with key of type ……but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
- EntityType 'UserInfo' has no key defined. Define the key for this EntityType.
- 关于 oracle record is locked by another user 问题解决办法
- LR场景运行提示:This Vuser already started a transaction with the same name, and has not yet processed the
- struts2关于A web application created a ThreadLocal with key of type 异常解决办法
- The web application [/struts2_0100] created a ThreadLocal with key of type
- 【hibernate】关于org.hibernate.ObjectNotFoundException: No row with the given identifier exists 的快捷解决问题
- error C4996: 'swprintf': swprintf has been changed to conform with the ISO C standard,set _CRT_NON_CONFORMING_SWPRINT
- The web application [/struts2_0100] created a ThreadLocal with key of type
- System.ArgumentException: 已添加了具有相同键的项。(An item with the same key has already been added) 在 System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) 在 System.Web.Mvc.Js
- 关于Hibernate中No row with the given identifier exists问题的原因及解决
- Fix The thread xxx has exited with code 259 (0×103)
- Android开发教程--关于Adapter的The content of the adapter has changed问题分析