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

[Jim Eng]

I was thinking the same thing, but so far it looks like the API  
exposes only the saveItem() method.  The update method is in the DAO  
and doesn't seem to be exposed beyond that.  I was hoping to avoid API  
changes.

BTW, it seems like the reason that updating an EvalScale did not fail  
is because the code that would retrieve an existing scale in the  
EvalAuthoringServiceImpl.saveScale() method has been commented out.   
The check whether it's an existing scale or new scale is by testing  
whether the id of the scale being saved is null, instead of testing  
whether it can be retrieved.

Still looking.

Jim


On Jan 22, 2010, at 12:19 PM, Aaron Zeckoski wrote:

> You could call update() instead of save(). Not sure that would fix
> things but it's an easy thing to try.
> -AZ
>
>
> On Fri, Jan 22, 2010 at 5:13 PM, Jim Eng <jimeng at umich.edu> wrote:
>> 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
>>>
>>>
>>
>>
>
>
>
> -- 
> Aaron Zeckoski (azeckoski (at) vt.edu)
> Senior Research Engineer - CARET - University of Cambridge
> https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski
> http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile
>
>