Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aperi-dev] Bugzillas

Hey Rodica,

Having traced through the code a bit myself, I believe your assessment of the problem is correct. In addition to the potential solutions you listed, we have another option. The default transaction isolation on all connections returned by DBConnPoolDataSource is TRANSACTION_READ_COMMITTED (constant integer value = 2):

A constant indicating that dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it.

We can work around the issue we're facing by setting the transaction isolation on the connection returned by DBConnPoolDataSource, in ViewReportTablesUpdater.updateViewTable(), to TRANSACTION_READ_UNCOMMITTED (constant integer value = 1):

A constant indicating that dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row.

After adding 'connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);' after 'connection = (DBConnection) ds.getPooledConnection();', the issue (which only seems to occur when attempting to remove a CIMOM against which discovery has been performed), disappeared in my workspace. Note that it isn't necessary to track and restore the isolation level of a connection, because it is automatically reset by DBConnPoolDataSource (line 113-114, in getPooledConnection()).

Now, given the nature of TRANSACTION_READ_UNCOMMITTED, and the fact that ViewReportTablesUpdater.updateViewTable() is called from multiple locations, I'm not sure that the option I've presented represents the best way to go. Hopefully, someone can take some time to perform further investigation. My sense is that updating the transaction isolation represents the easiest solution. However, if such would be problematic, either approach described in your e-mail would work fine.

I think we should move this discussion to Bugzilla, so that a record of this exchange is associated with the bug report. I'll also go ahead and post a patched version of the ViewReportTablesUpdater class. Hopefully, or IDVT team will be able to just drop the modified .class file into the org.eclipse.aperi.common plugin (to be safe, all four instances in our image), and proceed with testing.

Regards,
Khan Tasinga
IBM Tivoli Software Engineer / Aperi Development
Phone: (408) 284-5142 | T/L: 8-953-5142
Email: kmtasing@xxxxxxxxxx


Rodica Ciurea <rodica_ciurea@xxxxxxxxxx>
Sent by: aperi-dev-bounces@xxxxxxxxxxx

12/10/2006 07:47 AM

Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx>
To
Ted Slupesky/Portland/IBM@IBMUS
cc
Aperi Development <aperi-dev@xxxxxxxxxxx>, Viorel Ciurea <viorel_ciurea@xxxxxxxxxx>
Subject
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





_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev

Back to the top