[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aperi-dev] Bugzillas
|
Hi Ted,
I have looked at the bug and I found out that the Device Server hung
because it tried to retrieve the rows of the table T_RES_STORAGE_SUBSYSTEM
that had been modified (and therefore locked) as part of another
transaction not yet commited.
CIMOMManager.processPendingCIMOMDeletion opens a transaction by getting a
new connection:
DBConnection mConn = ServiceUtils.getConnection();
and after performing some DB operations calls markDevicesAsMissing that,
after performing other DB operations, performs the followings statements:
ChangeDetection mChangeDetection = new ChangeDetection(pConn);
mChangeDetection.complete(pConn, mTouchedEntities, pProcessID);
>From the complete method the processView method of the
ViewReportTablesUpdater class is called.
The processView method calls in turn updateViewTables, which gets a new
connection in order to update the associated view tables.
So, the ViewReportTablesUpdater.updateViewTables method creates a new
connection (and therefore performs its DB operations as part of a new
transaction associated with this new connection) and tries to retrieve from
T_RES_STORAGE_SUBSYSTEM. On the other hand, the DB operations from
CIMOMManager.processPendingCIMOMDeletion (and from other methods invoked
from it), including updating the T_RES_STORAGE_SUBSYSTEM table, have been
performed using another comnnection (and therefore as part of another
transaction) which has not yet been committed when
ViewReportTablesUpdater.updateViewTables method has been invoked.
There are two possible solutions depending whether the process of updating
the view tables is to be performed in the same transaction as the other DB
operations performed for deleting the CIMOM or in a different transaction:
1. If the update of the view tables is to be performed in the same
transaction as the delete CIMOM operations we should add a new parameter to
processView and updateViewTables in order to be able to transmit the
connection object.
2. If the update of the view tables is to be performed in a separate
transaction, we should move it after committing the delete CIMOM
transaction.
Regards,
Rodica
Ted Slupesky
<slupesky@xxxxxx.
com> To
Sent by: Aperi Development
aperi-dev-bounces <aperi-dev@xxxxxxxxxxx>
@eclipse.org cc
Subject
12/09/2006 01:38 Re: [aperi-dev] Bugzillas
AM
Please respond to
Aperi Development
<aperi-dev@eclips
e.org>
Definitely.
And can someone look at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=167175
It's assigned to Prasenjit, Major Severity -- but he won't be able to look
at it due to vacation.
--
Ted Slupesky | Eclipse Aperi Project Lead | IBM: 349-5413 | External: (503)
820-3853
Dave Wolfe/Portland/IBM@IBMUS
Sent by: aperi-dev-bounces@xxxxxxxxxxx
To
aperi-dev@eclips
12/08/2006 11:12 AM e.org
cc
Please respond to Subject
Aperi Development <aperi-dev@xxxxxxxxxxx> [aperi-dev]
Bugzillas
I think we should be sure to set the assignee to the actual fixer then the
fixer should: Accept bug (change status to ASSIGNED) whenever they start
working on a bug so we can tell which ones are in progress and which ones
can be reassigned.
Dave Wolfe/Portland/IBM (dwolfe@xxxxxxxxxx) TL: 775-3376 Office:
503-578-3376 Personal: 503-329-3960
GUI Technical Lead, Aperi Open Source Storage Management
http://www.eclipse.org/aperi http://www.ibm.com
If all of your problems look like nails you should invest in a good hammer
- Unknown_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev
