implementing a large table over a database

[Frank Fock]

Hi Dave,

Comments inline:

Dave Mason wrote:
> Hi,
> Hope you dont mind a follow-up to this, I'm still getting handle on 
> these methods.  I prefer the MibTable subclass approach, since the data 
> I'm working with is owned by an existing MibTable subclass produced by 
> AgentGen.  It would be pretty simple to add some new code there.  Any 
> extra detail about the update() method and Request accessors will help. 
> I see the parameter is a Request*, which must have a varbind with the 
> table's OID.  If the request is for one row only I guess the OID would 
> have the row's index appended?  In any case, as you say I need to read a 

Yes, that's right. But keep in mind that a request may access different
rows in the target table and also other objects in the agent.

> subset of the rows, stuff into memory for the rest of agent++, free the 
> memory when done, and repeat till all rows are read.  The comments for 
> update() say it only gets called once, so I'm not sure how to use it. 

The update method gets called at least once, but never after a request
has been finished. So you will have to stuff code to cleanup your cache
in the get_request method (and check there whether the request is about
to be finished).

> When I pre-populate a table, do I need to explitly generate each 
> MibTableRow, create the columnar objects, and set the values?
> 
Yes. You will have to create all rows completely that will be accessed
by the request. This can be hard to determine if it is a GETBULK
request with several repeaters. In this case it could be easier to
populate the whole table from a given index which is determined by the
minimum index of the objects referenced in the GETBULK request.

> Also, we wrote a simple database with the Gnu gdbm library instead of 
> using MySql.  libgdbm is not thread safe or reentrant, but I believe I 
> should be OK if I protect my database access with start_sync and end_sync?
> 
Yes it could be sufficient. But as I pointed out in my other email about
"mutex lock on persistence updates", be sure that the scope of the lock
is sufficient.


Best regards,
Frank

> Thanks again,
> Dave
> 
> Frank Fock wrote:
> 
>> Hi Dave,
>>
>> There have been several AGENT++ users that integrated
>> database access as part of table implementaions.
>> I recommend that you implement some generic approach
>> in your own MibComplexEntry or MibTable subclass.
>> You should use MibTable, if you users should be able to
>> create rows in the table. In other cases both approaches
>> have pros and cons.
>> If you choose to use MibTable, then you should overwrite
>> its update Method to create a view of a small (required)
>> portion of the table from the database when a request is
>> being processed. You will have to take some precautions
>> regarding synchronization between concurrent requests to
>> the same table.
>>
>> I have not used MySQL in C++ yet, so I cannot help here
>> (may be someone else can?).
>>
>> Best regards,
>> Frank
>>
>> Dave Mason wrote:
>>
>>> Hi all,
>>> I need to implement an alarm log, which will be a child of MibTable, 
>>> with rows and columns that will correspond to similar rows and 
>>> columns in a database.  The tables I have done before are entirely 
>>> memory resident because they don't grow continuously, but the log 
>>> table will keep growing.  I dont want to keep all the rows in memory, 
>>> so does anybody have a suggestion as to how to have the table object 
>>> read a row, update any new values (for a Set) or just return it (for 
>>> a Get), then delete the row from memory before moving to the next 
>>> row?  In a normal table, the table object creates a row, then the 
>>> columnar objects are responsible for getting their values.  In this 
>>> case, I'd like to operate on the whole row at once with a select or 
>>> update statement.  Maybe you need to to have a MibTableRow method 
>>> read the row into some temporary space, and let the columnar objects 
>>> get their data from there?  Any tips about that would help a lot.
>>>
>>> Also, I'll probably use some public domain database like mysql, which 
>>> I havent used before.  Questions about that are beyond the scope of 
>>> this list, but any tips on how to integrate it with Agent++ would be 
>>> very helpful too.
>>>
>>> Regards,
>>> Dave
>>>
> 
> 
>