when to lock a MibTable

[Frank Fock]

Hi Dave,

To get the index of a row call MibTableRow::get_index()

When you intend to delete rows from a table then it's
better not use get_rows_cloned since it has a significant
overhead and does not have any advantages compared with
iterating over MibTable::contents directly within the
MibTable::start_synch() .. end_synch() block.

Since get_rows_cloned is synchronized, you must not use
it within the MibTable::start_synch() .. end_synch() block.
When you call it before, you get a small synchronization
gap where the table could be changed externally. Thus,
searching the rows to delete and removing them must be
performed in the same synchronization block.

Best regards,
Frank

Dave Mason wrote:
> Oops - forgot one thing.  My table index column has access 
> not-accessible.  I prefer it that way so my index doesnt appear twice in 
> my manager (Explorer) display.  That means there's not MibLeaf object 
> for the index, so I probably can't do the row->first()->get_oid() I 
> mention below.  Is there another way to get the index Oid?
> 
> Sorry for the extra bandwidth :)
> 
> Dave
> 
> Dave Mason wrote:
> 
>> Hi,
>> This leads to a quick follow-up.  I'm adding or deleting a row inside 
>> a method as required.  Immediately before and after the table 
>> operation I do a table->start_synch() and end_synch()  as you 
>> mention.  To delete the rows, however, I need to call another method 
>> to scan through the whole table till I find the row with columnar 
>> values that match my criteria, then return a row pointer.  It appears 
>> I should use table->get_rows_cloned() to read the rows.  That method 
>> also calls start_synch() and end_synch().  Since I already called 
>> start_sync() before I get_rows_cloned(), will this make 
>> get_rows_cloned() block? Also, since I want to return the row pointer, 
>> will it be wrong to return the one from get_rows_cloned, because it's 
>> a clone and not the real one?  I believe your answer will be yes - in 
>> that case, should I return the Oid of the index, from 
>> row->first()->get_oid(), and then use table->find_index(oid) to get 
>> the row pointer to delete?  (The index is the first column in my table.)
>>
>> Thanks,
>> Dave
>>
>> Frank Fock wrote:
>>
>>> Hi Dave,
>>>
>>> Calling start_synch/end_synch around MibTable::remove_row *is*
>>> necessary! MibTable::fire_row_changed does synchronize
>>> *other* MibEntry instances that are listening for row change
>>> events of this MibTable.
>>> This implies that a table cannot listen for its own row
>>> events, because it otherwise would run into a deadlock when
>>> adding or deleting rows.
>>>
>>> Best regards,
>>> Frank
>>>
>>> Dave Mason wrote:
>>>
>>>> Hi Frank,
>>>> This is a quick follow-up to another answer you gave me a while 
>>>> back. You once said that if I call MibTable::remove_row (oid) to 
>>>> delete a row from a table, I should call table->start_synch and 
>>>> table->end_synch to lock out other threads during the delete.  I 
>>>> took another look at the remove_row code, and it calls 
>>>> fire_row_changed, which appears to do its own start_synch and 
>>>> end_synch.  Are the extra start_synch and end_synch in the user code 
>>>> necessary, or just an added precaution?  I see that 
>>>> MibTable::add_row works the same way, I assume the answer holds for 
>>>> it as well.  As before, I'm still on Agent++ v3.5.3a.
>>>>
>>>> Regards,
>>>> Dave
>>>>
>>>>