implementing a large table over a database

[Alex Finogenov]

Dave,

1. Since MibTable::update() may be called more than once (depends on the
combination of the varbind OID's in a request), you will have to figure out
a good way to reset your table(s) before processing the following request:
as far as I remember, agent++ does not have a MibTable method indicating
that a Get request is finished. Also, if your agent is for an embedded
environment, you will have to figure out how to optimize your operations
(i.e. retrieve data only once from the DB, etc.): I have found that the
straightforward way is too resource consuming (disk, CPU, and memory usage).

2. I implemented GetBulk in terms of GetNext. You will have to override
MibTable::find_succ(), which is called by during the processing of either
method, if I remember correctly.

3. Get methods are peanuts comparing to the Set, especially in when
implementing tables with AUGMENT clause, etc.

Alex F.

> -----Original Message-----
> From: Frank.Fock____t-online.de [mailto:Frank.Fock____t-online.de]
> Sent: Monday, October 28, 2002 2:42 PM
> To: Dave Mason
> Cc: Agent++ Mailing List
> Subject: Re: implementing a large table over a database
> 
> 
> 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
> >>>
> > 
> > 
> > 
> 
> 
> 
>