Persistency question...

[Frank Fock]

Hi Coung,

thank you very much for your comments / suggestions. I think you
have a very good understanding of how AGENT++ works inside.

I agree to all three points. I will try to implement something like
a VirtualMibTable for the next release (including an interface for
fine grain persistency). In my opinion, it will be sufficient to subclass
MibTable, but I am not sure...

Best regards,
Frank

Cuong Nguyen wrote:

> Hi folks,
>
> I just started looking over agent++ and have a few questions regarding
> persistency and other things.  I did read through the documentation and
> looked over the example codes before posting this message.  I'm new to this
> code so if I'm say something that is completely
> wrong please correct my assumption as appropriate.
>
> 1 - it seems that an entire MIB table is made persistent at a time.  For
> example the atmMib
>     example shows that an entire VPL table is stored and retrieved at once
> during
>     construction and destruction.  Now when a table consists of a very large
> number of
>     entries this could be a very time consuming and inefficient step.  For
> example, in
>     practical use an ATM VPL table could consists of tens of thousands of
> entries (or
>     more).  Are there other alternatives for this such as storing the
> entries in indexed
>     file and retrieving a row at a time instead of an entire table?  What I
> would like to
>     do is not retrieve the row until it is actually accessed because of a
> request rather
>     than at the time of construction.  I guess I can do this using the
> mechanism described
>     in my second question below.
>
> 2 - Similar to the question 1, I have question for get_next.  Currently it
> looks like the
>     "get_next" processing is handled completely by the agent++ toolkit.
> This makes sense
>     again for smaller agent implementation but for large tables such as ATM
> VPL, this would
>     be problematic since the agent expects to know about all the entries in
> the table (all
>     entries must be added specifically).  Currently, when a get_next is
> requested, the
>     Mib::find routine is executed which searches the "content" list which is
> a list of all
>     existing rows (again it looks like all rows must have been previously
> added to the
>     agent).  What I would like to be able to do is to have virtual rows that
> does not
>     have to be added to the MIB until it is requested by someone.  So when
> get_next is
>     called I would like to have an opportunity to add the row at that time.
> I guess I can
>     do this myself by overloading the "get_next" routine for a given table.
> Then, I can
>     look in my own cache to see if the object exists then check to see if it
> is in the
>     "content" list already or not.  If not I can add it to the content list.
> I guess I
>     would also like to remove the entry from cache at some point (when?).  I
> would refresh
>     my cache from persistent storage if the cache object does not exist.  If
> the object
>     is not in persistent storage either then I would not add to the
> "content" list which
>     would result in a "no-such-name" error from get_next.  It would be nice
> if this behavior
>     is modeled in the library so I don't end up just hacking it :-).
>
> 3 - another similar issue is when a MIB table and all rows are derived
> dynamically or maybe
>     is a model of a database or log file.  In this case it is not efficient
> to load the
>     entire log file or database in at the time of construction.  It would be
> better if only
>     the required row is retrieved at the time of request.  In this case the
> agent library
>     might want to provide a method by which the agent call the "table" (not
> entry) object
>     to retrieve the row in question at the point of request.  This means
> that the agent
>     does not know at all whether the row is present and must leave the
> determination to
>     runtime code.  The agent library may also need help from runtime code to
> determine if
>     a column exists.  To do get_next in this case the agent library will
> also have to
>     delay the determination of the next valid "row" in a table to runtime
> code.
>
> Again, I'm new to this code so if I'm totally off in my understanding of the
> code please
> forgive me.  Thank you for your time.
>
> Cuong.