[Contrib: Evaluation System] Help with DB transactions when using AuthoringService API

[Jim Eng]

Here's an update with what I've found so far.

I watched the MySQL query log while stepping through the code and  
found that each existing EvalItem is retrieved twice -- once in my  
code and once in EvalAuthoringServiceImpl while my code is trying to  
update the existing item.

My code retrieves the existing entity by EID.  That results in these  
two queries:

select this_.ID as ID89_1_, this_.EID as EID89_1_, this_.LAST_MODIFIED  
as LAST3_89_1_, this_.OWNER as OWNER89_1_, this_.ITEM_TEXT as  
ITEM5_89_1_, this_.DESCRIPTION as DESCRIPT6_89_1_, this_.SHARING as  
SHARING89_1_, this_.CLASSIFICATION as CLASSIFI8_89_1_, this_.EXPERT as  
EXPERT89_1_, this_.EXPERT_DESCRIPTION as EXPERT10_89_1_,  
this_.SCALE_FK as SCALE11_89_1_, this_.USES_NA as USES12_89_1_,  
this_.USES_COMMENT as USES13_89_1_, this_.DISPLAY_ROWS as  
DISPLAY14_89_1_, this_.SCALE_DISPLAY_SETTING as SCALE15_89_1_,  
this_.COMPULSORY as COMPULSORY89_1_, this_.CATEGORY as CATEGORY89_1_,  
this_.LOCKED as LOCKED89_1_, this_.COPY_OF as COPY19_89_1_,  
this_.HIDDEN as HIDDEN89_1_, this_.AUTO_USE_TAG as AUTO21_89_1_,  
evalscale2_.ID as ID93_0_, evalscale2_.EID as EID93_0_,  
evalscale2_.LAST_MODIFIED as LAST3_93_0_, evalscale2_.OWNER as  
OWNER93_0_, evalscale2_.TITLE as TITLE93_0_, evalscale2_.SCALE_MODE as  
SCALE6_93_0_, evalscale2_.SHARING as SHARING93_0_, evalscale2_.EXPERT  
as EXPERT93_0_, evalscale2_.EXPERT_DESCRIPTION as EXPERT9_93_0_,  
evalscale2_.IDEAL as IDEAL93_0_, evalscale2_.LOCKED as LOCKED93_0_,  
evalscale2_.COPY_OF as COPY12_93_0_, evalscale2_.HIDDEN as HIDDEN93_0_  
from EVAL_ITEM this_ left outer join EVAL_SCALE evalscale2_ on  
this_.SCALE_FK=evalscale2_.ID where (this_.EID='11111')

select options0_.ID as ID0_, options0_.SCALE_OPTION as SCALE2_0_,  
options0_.SCALE_OPTION_INDEX as SCALE3_0_ from EVAL_SCALE_OPTIONS  
options0_ where options0_.ID=34

Then a little later, my code calls  
EvalAuthoringServiceImpl.saveItem().  In that method, the EvalItem is  
retrieved again, at line 398:

EvalItem existingItem = getItemOrFail(item.getId());

That results in two more queries:

select evalitem0_.ID as ID89_1_, evalitem0_.EID as EID89_1_,  
evalitem0_.LAST_MODIFIED as LAST3_89_1_, evalitem0_.OWNER as  
OWNER89_1_, evalitem0_.ITEM_TEXT as ITEM5_89_1_,  
evalitem0_.DESCRIPTION as DESCRIPT6_89_1_, evalitem0_.SHARING as  
SHARING89_1_, evalitem0_.CLASSIFICATION as CLASSIFI8_89_1_,  
evalitem0_.EXPERT as EXPERT89_1_, evalitem0_.EXPERT_DESCRIPTION as  
EXPERT10_89_1_, evalitem0_.SCALE_FK as SCALE11_89_1_,  
evalitem0_.USES_NA as USES12_89_1_, evalitem0_.USES_COMMENT as  
USES13_89_1_, evalitem0_.DISPLAY_ROWS as DISPLAY14_89_1_,  
evalitem0_.SCALE_DISPLAY_SETTING as SCALE15_89_1_,  
evalitem0_.COMPULSORY as COMPULSORY89_1_, evalitem0_.CATEGORY as  
CATEGORY89_1_, evalitem0_.LOCKED as LOCKED89_1_, evalitem0_.COPY_OF as  
COPY19_89_1_, evalitem0_.HIDDEN as HIDDEN89_1_,  
evalitem0_.AUTO_USE_TAG as AUTO21_89_1_, evalscale1_.ID as ID93_0_,  
evalscale1_.EID as EID93_0_, evalscale1_.LAST_MODIFIED as LAST3_93_0_,  
evalscale1_.OWNER as OWNER93_0_, evalscale1_.TITLE as TITLE93_0_,  
evalscale1_.SCALE_MODE as SCALE6_93_0_, evalscale1_.SHARING as  
SHARING93_0_, evalscale1_.EXPERT as EXPERT93_0_,  
evalscale1_.EXPERT_DESCRIPTION as EXPERT9_93_0_, evalscale1_.IDEAL as  
IDEAL93_0_, evalscale1_.LOCKED as LOCKED93_0_, evalscale1_.COPY_OF as  
COPY12_93_0_, evalscale1_.HIDDEN as HIDDEN93_0_ from EVAL_ITEM  
evalitem0_ left outer join EVAL_SCALE evalscale1_ on  
evalitem0_.SCALE_FK=evalscale1_.ID where evalitem0_.ID=97

select options0_.ID as ID0_, options0_.SCALE_OPTION as SCALE2_0_,  
options0_.SCALE_OPTION_INDEX as SCALE3_0_ from EVAL_SCALE_OPTIONS  
options0_ where options0_.ID=34

Then at line 436, after validation and fix-up, the DAO's save() method  
is called to save the item that was passed in from my code (not the  
one retrieved in the saveItem() method):

dao.save(item);

That's when the exception is thrown.

I don't see any other queries of the EVAL_ITEM table. Still looking.

Jim


On Jan 22, 2010, at 10:33 AM, Aaron Zeckoski wrote:

> On Fri, Jan 22, 2010 at 3:19 PM, Jim Eng <jimeng at umich.edu> wrote:
>> I am using XStream to deserialize the XML.  XStream creates an  
>> EvalItem
>> object with the EID set appropriately and all the properties set
>> appropriately.  The id of that EvalItem is null.
>>
>> Once the servlet validates the properties in the new EvalItem  
>> object, we try
>> to retrieve an EvalItem with the same EID.  If that's null, we save  
>> the new
>> one that was created by XStream.  That works fine.  If it's not  
>> null, we
>> systematically copy property values from the new item into the one  
>> that was
>> retrieved from the AuthoringService, and then we save that one.
>>
>> Is it possible that something in XStream might be interacting with
>> hibernate?  Do you think the constructor for an EvalItem cause any  
>> hibernate
>> activity?
>
> I don't think so. The classes themselves have no hibernate bindings.
> What you are doing sounds like it should work though you may need to
> be careful that you are not loading up any items twice (I would hope
> that is ok but hibernate is weird sometimes).
>
> -AZ
>
>