In reverse order:
> For example, if the first request created a row in a table (plus some
other stuff), and the second request changed a value from that row.
> If the first request fails, then the second can't be acted on.
In your example you talk about a case where the request PDU has several
requests for the same table.
If the requests are for the same table, then they will go to the same
sub-agent.
So the sub-agent (which processes the requests synchronously) will get
an error in the first request (create row) and will not process the
second request.
So we don't need the netsnmp_processing_set flag in this case.
> But if you let a "smaller" SET be acted upon while the delegated part
of a previous SET is still outstanding, the two could potentially be in
conflict.
The thing is that the sub-agents are synchronous, so the "smaller" SET
can not be acted upon before the delegated is processed.
> What happens if the delegated set fails, and the previous values need
to be restored?
Well I guess that if the request PDU includes request for different
sub-agents, then a value-restore would be difficult in the following
scenario:
- sub-agent-A applies tha change
- sub-agent-A applies more changes (from a secind request PDU, which was
not blocked by the netsnmp_processing_set flag)
- sub-agent-B failes
Is that the scenario you intended?
NOTE: I'm assuming that the master agent gathers all the requests within
a PDU (which should be dispatched to a certain sub-agent)
and sends them all to the sub-agent in one agentX PDU.
Is that correct?
Erez.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Shield
Sent: Wednesday, March 21, 2007 2:06 PM
To: Makavy, Erez (Erez)
Cc: [email protected]
Subject: Re: Why do we need the netsnmp_processing_set global variable?
On 21/03/07, Makavy, Erez (Erez) <[EMAIL PROTECTED]> wrote:
> Why do we have to wait for delegated sets to finish (when
> processing_set !=NULL),
> - if the Current request is for the same delegated sub-aagent, then
> there is no problem , the sub-agent is syncronious,
> and will finish the delegated request before handling the current
request.
> - if the request is for a different sub-agent, then there is no issue
> of accessing non-current data.
What happens if the delegated set fails, and the previous values need to
be restored?
With the current situation, that's not going to be qa problem.
But if you let a "smaller" SET be acted upon while the delegated part of
a previous SET is still outstanding, the two could potentially be in
conflict.
For exanmple, if the first request created a row in a table (plus some
other stuff), and the second request changed a value from that row.
If the first request fails, then the second can't be acted on.
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
