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

Aaron Zeckoski aaronz at vt.edu
Fri Jan 22 09:19:37 PST 2010


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


More information about the evaluation mailing list