Re: strange optimistic locking failure (ERXPartials Problem)
Re: strange optimistic locking failure (ERXPartials Problem)
- Subject: Re: strange optimistic locking failure (ERXPartials Problem)
- From: Tim Worman <email@hidden>
- Date: Wed, 12 Jun 2013 12:37:29 -0700
On Jun 12, 2013, at 10:32 AM, Chuck Hill <email@hidden> wrote:
>
> On 2013-06-11, at 2:36 PM, Tim Worman wrote:
>
>> OK, I have successfully committed a record without an exception but it came at a big price - so I'm gonna do more testing. So, for:
>>
>> entity PERSON
>> partial entity EMPLOYEE
>>
>> I try a single change - setting shouldSync=TRUE
>>
>> If I remove the partial entity framework from the build path I can save this change cleanly. When the partial entity framework is in the build path, it considers all of the partial entities attributes "locked." They are not in their model though.
>
> I think that David Aspinall was likely one of the last to work on partials. He is away this week but may be able to shed some light next week. Did a Wonder update cause this? If so, you could also look for recent-ish changes to this in Wonder.
>
>
> Chuck
Thanks for the appending to the subject - I was just about to do that. Yeah, I am on integration so it could be that there's a new problem. I need to look at the commits.
I can tell you what I've done to try to work around it. In ERXPartialInitializer.initializePartialEntities(EOModelGroup):
I added some code to explicitly setAttributesUsedForLocking(NSArray) with a Set comprised of locking attributes in the base and partial entity. It doesn't work - in the app right before I save changes, I log out the locking attributes and it still includes a bunch of stuff from the partial entity that aren't set to lock in the model. In a quick scan I can't find any code (other than what I added above) that explicitly sets the locking attributes in the base entity.
Tim
>
>> All the partial's unique attributes show up in the WHERE clause of the UPDATE statement. One of these is obviously causing the lock error. Example:
>>
>> UPDATE PERSON SET should_sync = ? WHERE (person_id = ? AND modify_date = ? AND comp_time_bal = ? AND emergency_info = ? AND emp_rel_code = ? AND norm_vac_max is NULL AND out_of_office = ? AND pto_hrs_bal = ? AND sick_lv_hrs_bal = ? AND start_begin_date is NULL AND start_end_date is NULL AND start_percent = ? AND vac_hrs_balance = ? AND work_addr_city is NULL AND work_addr_line1 = ? AND work_addr_line2 is NULL AND work_addr_state is NULL AND work_addr_zip is NULL)" withBindings: 1:true(shouldSync), 2:12505(personId), 3:2012-02-14 14:30:15(modifyDate), 4:0.0(compTimeBal), 5:""(emergencyInfo), 6:""(empRelCode), 7:false(outOfOffice), 8:0.0(ptoHrsBal), 9:0.0(sickLvHrsBal), 10:0(startPercent), 11:0.0(vacHrsBalance), 12:""(workAddrLine1)>
>>
>> Without the partial entity in the build path, the update statement looks like:
>>
>> UPDATE PERSON SET should_sync = ? WHERE (person_id = ? AND modify_date = ?)" withBindings: 1:true(shouldSync), 2:12505(personId), 3:2012-02-14 14:30:15(modifyDate)>
>>
>> Which is completely what I'd expect since I only lock on person_id and modify_date. My assumption is something is wrong in my framework - it obviously WAS working. I definitely want to rule out a broader problem.
>>
>> Thanks,
>>
>> Tim
>>
>> On Jun 11, 2013, at 1:19 PM, Tim Worman <email@hidden> wrote:
>>
>>> Do you mean in your prototype models or in your entity models? I have only ever locked on primary key and modifyDate. I know I mentioned in a previous thread that this has always worked well.
>>>
>>> The FrontBase prototype model only locks on 'id' and 'boolean' attributes. The OpenBase attribute model locks every attribute type almost. I'm really lost as to what is going on. So, the question is, how can an EO I just fetched think it has changed when it has not?
>>>
>>> Tim
>>>
>>> On Jun 11, 2013, at 9:54 AM, Chuck Hill <email@hidden> wrote:
>>>
>>>> In my models, most attributes are locked.
>>>>
>>>> Chuck
>>>>
>>>>
>>>> On 2013-06-11, at 9:32 AM, Tim Worman wrote:
>>>>
>>>>> 'Locked' is definitely not enabled for those attributes in the model - or in partial entity that is built on that entity.
>>>>>
>>>>> This is the first time I've ever examined the locking in EOJDBCOpenBasePrototypes. They do look ODD to me. I am using Wonder -> integration. The MySQL and Oracle prototypes have a ton of locked attributes as well.
>>>>>
>>>>> <PastedGraphic-1.png>
>>>>>
>>>>> On Jun 11, 2013, at 8:38 AM, Chuck Hill <email@hidden> wrote:
>>>>>
>>>>>> No, I was just trying to think of anything that might alter the WHERE from what you would expect looking at the entity in the EOModel.
>>>>>>
>>>>>> Have you double checked that locked did not get turned on these attributes in the model? Are you using prototypes? Did locking change on the prototypes?
>>>>>>
>>>>>>
>>>>>> Chuck
>>>>>>
>>>>>>
>>>>>> On 2013-06-11, at 8:18 AM, Tim Worman wrote:
>>>>>>
>>>>>>> Hi Chuck et al:
>>>>>>>
>>>>>>> I wasn't sure if maybe I was missing something in your question - so, is this locking behavior I should expect when using partials? I don't recall seeing an update statement like that in the past.
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>> On Jun 10, 2013, at 3:38 PM, Tim Worman <email@hidden> wrote:
>>>>>>>
>>>>>>>> Thanks Chuck.
>>>>>>>>
>>>>>>>> I am using ERXPartials. I've done a couple of deployments including partial support and it had been working well. This problem just started recently - really seemed to come out of the blue. The exception is reproducible in development so there is no other app touching the database.
>>>>>>>>
>>>>>>>> Tim
>>>>>>>> UCLA GSE&IS
>>>>>>>>
>>>>>>>> On Jun 10, 2013, at 3:35 PM, Chuck Hill <email@hidden> wrote:
>>>>>>>>
>>>>>>>>> Are you using inheritance or partials?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2013-06-10, at 3:33 PM, Tim Worman wrote:
>>>>>>>>>
>>>>>>>>>> I am suddenly getting strange optimistic locking failures when when updating a row on ec.saveChanges(). At least it seems sudden to me because I can't introspect well enough to see where I caused it. :-) I'm seeing this.
>>>>>>>>>>
>>>>>>>>>> Jun 10 15:14:02 eTimesheet[55555] INFO er.transaction.adaptor.Exceptions - Database Exception occured: com.webobjects.eoaccess.EOGeneralAdaptorException: updateValuesInRowDescribedByQualifier -- com.webobjects.jdbcadaptor.JDBCChannel method failed to update row in database.
>>>>>>>>>>
>>>>>>>>>> So, I logged at the SQL and capture the userInfo() on the exception. What really caught my eye is the update statement that was produced. The WHERE statement makes it seem like is locking on every attribute in the PERSON entity. My model definitely does not reflect that should be happening.
>>>>>>>>>>
>>>>>>>>>> UPDATE PERSON SET campus_mail_code = ?, should_sync = ?, person_first_name = ?, start_end_date = ?, norm_vac_max = ?, student_status = ?, start_begin_date = ?, campus_phone = ?, home_dept_code = ?, person_middle_name = ?, email_address_other = ?, emp_status = ?, work_addr_line2 = ?, emp_rel_code = ? WHERE (person_id = ? AND modify_date = ? AND comp_time_bal = ? AND emergency_info = ? AND emp_rel_code = ? AND norm_vac_max is NULL AND out_of_office = ? AND pto_hrs_bal = ? AND sick_lv_hrs_bal = ? AND start_begin_date is NULL AND start_end_date is NULL AND start_percent = ? AND vac_hrs_balance = ? AND work_addr_city is NULL AND work_addr_line1 = ? AND work_addr_line2 is NULL AND work_addr_state is NULL AND work_addr_zip is NULL)
>>>>>>>>>>
>>>>>>>>>> Can anyone help explain the abnormal growth of my WHERE clause?
>>>>>>>>>>
>>>>>>>>>> Tim
>>>>>>>>>> UCLA GSE&IS
>>>>>>>>>> ________________________________
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden