本文介绍了ATG RepositoryItem getPropertyValue,无缓存,无交易的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果我有一个不可缓存的ATG Nucleus存储库项目(禁用了ATG/Nucleus简单缓存)并且我不在事务中,则以下结果将导致对数据库的两次查询.

If I have an ATG Nucleus Repository Item that is not cacheable (ATG/Nucleus simple cache is disabled) AND I'm not in a transaction, the following results in two queries to the database.

以下代码将对每个属性进行数据库查询.repositoryItem.getPropertyValue("columnA");repositoryItem.getPropertyValue("columnB");

The following code results in a db query for every property.repositoryItem.getPropertyValue("columnA");repositoryItem.getPropertyValue("columnB");

如果启用了针对用户实体的调试,则每次调用都会看到以下日志语句:

If debugging for the user entity is enabled you would see the following log statements ever each call:

repositoryItem.getPropertyValue("columnA"); 无法为此事务禁用DEBUG loadingPropertyFromDatabase(user:ID_1.columnA,column_a_value)属性无法为此事务禁用DEBUG loadingPropertyFromDatabase(user:ID_1.columnB,column_b_value)属性调试getPropertyValue(user:ID_1.columnA)->"column_a_value"(数据库中的值)

repositoryItem.getPropertyValue("columnA");DEBUG loadingPropertyFromDatabase(user:ID_1.columnA, column_a_value) property is not cacheable caching disabled for this transactionDEBUG loadingPropertyFromDatabase(user:ID_1.columnB, column_b_value) property is not cacheable caching disabled for this transactionDEBUG getPropertyValue(user:ID_1.columnA) -> "column_a_value" (value from database)

repositoryItem.getPropertyValue("columnB"); 无法为此事务禁用DEBUG loadingPropertyFromDatabase(user:ID_1.columnA,column_a_value)属性无法为此事务禁用DEBUG loadingPropertyFromDatabase(user:ID_1.columnB,column_b_value)属性调试getPropertyValue(user:ID_1.columnB)->"column_b_value"(数据库中的值)

repositoryItem.getPropertyValue("columnB");DEBUG loadingPropertyFromDatabase(user:ID_1.columnA, column_a_value) property is not cacheable caching disabled for this transactionDEBUG loadingPropertyFromDatabase(user:ID_1.columnB, column_b_value) property is not cacheable caching disabled for this transactionDEBUG getPropertyValue(user:ID_1.columnB) -> "column_b_value" (value from database)

由于其他系统正在访问/更新对象,因此我们无法启用缓存.

We cannot enable caching, due to how the object is being access/updated by other systems.

我也不想为实体的只读查询创建事务.

I also do not want to create a transaction for a read only query of the entity.

如果我使用的是Hibernate,则即使我不在事务中,Hibernate会话也会在该会话内保持状态.ATG/Nucleus似乎并非如此.有什么办法可以得到这种类型的行为或线程级缓存?

If I was using Hibernate, the Hibernate session would keep a state within the session, even if I was not in a transaction. That doesn't seem to be the case with ATG/Nucleus. Is there any way I can get this type of behavior or a thread level cache?

在查看文档并通过调试器(不带源代码)很难遍历代码时,我没有运气可寻.

In looking at documentation and walking through the code via debugger (which is difficult w/out source), I am not having any luck finding a work around.

谢谢!

推荐答案

您需要用事务包装 getPropertyValue 调用,该事务会将数据库查询的结果保存到临时事务缓存中.这样可以防止每次 getPropertyValue 调用都使存储库返回数据库.

You need to wrap the getPropertyValue calls with a transaction which will save the results of the database queries into the temporary transaction cache. That will prevent the repository from going back to the database for every getPropertyValue call.

您还希望确保所访问的所有属性都属于同一属性组(如此处).从数据库中第一次加载项目将拉入与ID属性在同一组中的属性.加上事务缓存,将大大减少数据库查询的数量.

You also want to ensure that all the properties you are accessing are part of the same property group (as described here). The first load of the item from the database will pull in the properties in the same group as the ID property. This combined with the transaction cache will significantly reduce the number of database queries.

我不明白您为什么不想明确地划分交易范围.如果尚未存在,则每个 getPropertyValue 调用都会自动创建(并结束)交易.因此,在您的示例中,您将为您隐式创建2个事务.为什么不只显式地创建1个事务?

I don't understand why you wouldn't want to explicitly demarcate a transaction. Every getPropertyValue call will automatically create (and end) a transaction if one isn't already present. So in your example, you would have 2 transactions implicitly created for you. Why not just create 1 transaction explicitly?

这篇关于ATG RepositoryItem getPropertyValue,无缓存,无交易的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-22 08:31