ItEr76S14ConcurrencyProblemWorkReports
TWiki>
LibrePlan Web>ItEr76S14ConcurrencyProblemWorkReports (19 Oct 2012, ManuelRego)EditAttach
| Story summary | Concurrency problems work reports |
| Iteration | ItEr76Week01To33 |
| FEA | ItEr76S14ConcurrencyProblemWorkReports |
| Story Lead | |
| Next Story | |
| Passed acceptance test | No |
Acceptance Criteria
Additional Specification Comments
Implementation Notes
Started to change the mapping and detected that we need to get rid of column sum_charged_effort_id in order_element table.
So finally the mapping will be as follows:
-
In OrderElement:
<one-to-one name="sumChargedEffort" class="SumChargedEffort" cascade="delete" property-ref="orderElement" /> -
In SumChargedEffort:
<many-to-one name="orderElement" column="order_element" class="OrderElement" cascade="none" unique="true" />
This implies to do a migration of data, moving info from column sum_charged_effort_id in order_element table to a new column order_element in sum_charged_effort table. In order to do this data migration it was needed to use specific procedures for PostgreSQL and MySQL.
-- ManuelRego - 28 Mar 2012
Methods to update and create the SumChargedEffort has been moved from OrderElementDAO to SumChargedEffortDAO (actually the SumChargedEffort entities were created before by default every time an OrderElement was created).
In these methods a map is used to avoid query the database once the SumChargedEffort corresponding to an OrderElement has already been found before.
-- ManuelRego - 30 Mar 2012
It has been implemented the solution explained in the analysis adding a method recalculateSumChargedEfforts in SumChargedEffortDAO and an attribute neededToRecalculateSumChargedEfforts in Order.
Anyway it should be reviewed the possibility to use a thread for the recalculations in SumChargedEffortDAO. And avoid the current problem of concurrency that has been added again with this task.
-- ManuelRego - 02 Apr 2012
Finally a thread to do this recalculations has been added.
The thread uses a BlockingQueue which provides 2 methods (put and take) that make easier the development of the thread.
The thread is launched in the constructor of a singleton class called SumChargedEffortRecalculator (this class is created by Spring). The thread has an infinite loop and it waits in the method take till there's any element in the queue in order to be recalculated.
Finally, a BlockingQueue was not needed and it was enough with a single [http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ExecutorService.html][ExecutorService]] which is in charge of run the thread that do the recalculations one by one.
The previous patch was modified to change the behavior explained in the strike-through text above for the new one.
-- ManuelRego - 04 Apr 2012
Delay Causes
Final or Pending Considerations
-
Review problems in procedure with PostgreSQL 8. For the moment the solution is execute the following sentence with PostgreSQL superuser:
CREATE LANGUAGE plpgsql;
%RPSHOWGITCOMMITS%
| User | Spent in XpTracker | Spent in phpReport | Ok? |
|---|---|---|---|
| ManuelRego | 25.75 | 0 |  |
| Total | 25.75 | 0 | |
Copyright (c) by the contributing authors. All material on this collaboration platform is the property of the contributing authors.