Great Circle Associates Network-Automation
(April 2005)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: CLI transactions
From: Daniel Hagerty <hag @ linnaean . org>
Date: Sat, 16 Apr 2005 14:20:46 -0400
To: "Min Qiu" <mqiu @ pop2pop . com>
Cc: "Kirby Files" <ksfiles @ gmail . com>,"Network Automation List" <network-automation @ greatcircle . com>
In-reply-to: <9BD20C9B8D21C04FA661826D202E631F01E2983A@gicorp0.gicorp.mypop2pop.com>
References: <9BD20C9B8D21C04FA661826D202E631F01E2983A@gicorp0.gicorp.mypop2pop.com>
Reply-to: Daniel Hagerty <hag @ linnaean . org>

 > This may bring us back to the previous modeling discussion...
 > Since the goal is automation, the NMS will be the system
 > talk to the device via CLI, SNMP or API.  The 3 phase commits
 > can be in the NMS or router, it does not matter.  Of cause,
 > implement it in NMS will make it more genernal(a modeling
 > topic)
 >
 > Right?

    Certainly as you get to extremes, sure.  I'm guessing pure network
administration doesn't need to go there very often tho.

    In some kinds of large systems, deeply nested transactions are the
norm.

    For example, if I write a message driven EJB that accepts messages
from a transactional queue system and somehow puts them in a
transactional database, both the queue system and the database system
see themselves as "the transaction manager".  But to the larger
system, these two transactions are nested and controlled by another
transaction manager that actually ensures that both transactions
behave as one.


References:
Indexed By Date Previous: Re: CLI transactions
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
Next: Re: CLI transactions
From: Andrew Fort <andrew.fort@gmail.com>
Indexed By Thread Previous: Re: CLI transactions
From: Kirby Files <ksfiles@gmail.com>
Next: Re: CLI transactions
From: "Min Qiu" <mqiu@pop2pop.com>

Google
 
Search Internet Search www.greatcircle.com