when to lock a MibTable

[Dave Mason]

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
>>>
>>>