Though i did not do exactly like what you said, your mail did give me an
idea on how to implement the stuff.
Find my comments inline
On 10/15/07, Robert Story <[EMAIL PROTECTED]> wrote:
>
> On Wed, 12 Sep 2007 19:09:31 +0530 deepak wrote:
> DB> When a set request is received, my sub-agent completes this operation
> using
> DB> transactional semantics. If a set request had come for more than 1
> attribute
> DB> for the same table, then this set would be done as part on one
> transaction.
> DB> [...]
> DB> Now consider when a set is done on attributes belonging to different
> table
> DB> [...]
> DB> Like before, my sub-agent is expected to process the request as a
> single
> DB> transaction. The problem is there is a handler generated per table(say
> h1
> DB> and h2 for tables t1 and t2) and my sub-agent has no way of knowing
> whether
> DB> the set requests that come through h1 and h2 is part of the same bulk
> set
> DB> request.
> DB> What i want is some way to recognize that all these set requests for
> DB> different attributes are part of one single request, so that i can
> DB> accumulate the jobs and then start a single transaction to complete
> this
> DB> request.
>
> First of all, you shouldn't say 'bulk set', since there really isn't such
> a
> thing, just to keep from confusing the newbies.
>
> Now, on to your question about sets with multiple tables. There is no API
> in
> net-snmp for associating multiple tables/object with different base OIDs.
> There are 2 ways for accomplishing what you want:
>
> 1) register a handler at the highest common base OID node. That handler
> would
> then have to do lots of the work that the agent is currently doing for
> you.
> Probably not what you want.
>
> 2) Use reference counting. You can add a pointer to the request data list,
> and
> count the number of times you see the SET_RESERVE1 state in the handlers
> with
> shared state.
Not sure what u mean by shared state here? This is what i did to make it
work, in the ACTION phase, the request is added to a container which is
being sent to process in COMMIT phase.
So when multiple requests come, all of them goes to a container which is
then committed at a single go when the ACTION phase for one of the handler
is reached. The other handlers would know that the request is already sent
and return back by checking the state of the container.
It did work fine.
--
Regards,
Deepak B.
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
