tpcc_current (Дополнительные методические материалы), страница 6

It m u st be p ossible to key in only significant characters into field s. For alp hanu m eric field s, non -keyedp ositions m u st be translated to blanks or nu lls. For n u m eric field s, keyed inp u t of less than the m axim umallow able d igits m u st be p resented right ju stified on th e ou tp u t screen.5. All field s for w hich a valu e is necessary to allow the ap p lication to com p lete are requ ired to contain inp u tp rior to the start of the m easu rem ent of the transaction RT, or the ap p lication m u st contain a set of error hand ling rou tines to inform the u ser that requ ired field s have not been entered .6. Field s can be keyed and re-keyed in any ord er. Sp ecifically:•The em u lated u ser m u st be able to m ove the inp u t cu rsor forw ard and backw ard d irectly to the inp u tcap able field s.•The ap p lication cannot rely on field s being entered in any p articu lar ord er.•The u ser can retu rn to a field that has been keyed in and change its valu e p rior to the start of them easu rem ent of the transaction RT.7.

N u m eric field s m u st be p rotected from non -nu m eric inp u t. If one or m ore non -nu m eric characters is enteredin a nu m eric field , a d ata entry error m u st be signaled to the u ser.Comment: Inp u t valid ation m ay either be p erform ed by the term inal, by the ap p lication , or a com bination ofboth. Inp u t valid ation requ ired by Item 5 and Item 7 m u st occu r p rior to starting a d atabase transaction .Sp ecifically, invalid d ata entry m ay not resu lt in a rolled back transaction.TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 24 of 1302.2.2.5All ou tp u t field s that d isp lay valu es that are u p d ated in the d atabase by the cu rrent bu sinesstransaction m u st d isp lay the "new " (i.e., com m itted ) valu es for those field s.TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 25 of 1302.3General Requirements for Transaction ProfilesEach transaction m u st be im p lem ented accord ing to the sp ecified transaction p rofiles .

In ad d ition:2.3.1The ord er of the d ata m anip u lation s w ithin the transaction bou nd s is im m aterial (u nless o therw isesp ecified , see Clau se 2.4.2.3), and is left to the latitu d e of the test sp onsor , as long as the im p lem ented transactionsare fu nctionally equ ivalent to those sp ecified in the transaction p rofiles .2.3.2The transaction p rofiles sp ecify m inim al d ata retrieval and u p d ate requ irem ents for the transactions.Ad d itional navigational step s or d ata m anip u lation op erations im p lem ented w ithin the d atabase transactions m u stbe d isclosed , and the p u rp ose of su ch ad d ition(s) m u st be exp lained .2.3.3Each attribu te m u st be obtained from the d esignated table in the transaction p rofiles .Comment: The intent of this clau se is to p revent red u cing the nu m ber of logical d atabase op erations requ ired toim p lem ent each transaction.2.3.4N o d ata m anip u lation op eration from the transaction p rofile can be p erform ed before all inp u t d atahave been com m u nicated to the SUT, or after any ou tp u t d ata have been com m u nicated by the SUT to the em u latedterm inal.Comment: The intent of this clau se is to ensu re that, for a given bu siness transaction , no d ata m anip u lationop eration from the transaction p rofile is p erform ed p rior to the tim estam p taken at the beginning of the TransactionRT or after the tim estam p taken at the end of the Transaction RT (see Clau se 5.3).

For exam p le, in the N ew -Ord ertransaction the SUT is not allow ed to fetch the m atching row from the CUSTOMER table u ntil all inp u t d ata havebeen com m u nicated to the SUT, even if this row is fetched again later d u ring the execu tion of that sam e transaction.2.3.5If transactions are rou ted or organized w ithin the SUT, a com m ercially available transactionp rocessing m onitor or equ ivalent com m ercially available softw are (hereinafter referred to as TM ) is requ ired w iththe follow ing featu res/ fu nctionality:Operation - The TM m u st allow for:• requ est/ service p rioritization• m u ltip lexing/ d e m u ltip lexing of requ ests/ services• au tom atic load balancing• recep tion, qu eu ing, and execu tion of m u ltip le requ ests/ services concu rrentlySecurity - The TM m u st allow for:• the ability to valid ate and au thorize execu tion of each service at the tim e the service is requ ested .• the restriction of ad m inistrative fu nctions to au thorized u sers.Administration/Maintenance - The TM m u st have the p red efined cap ability to p erform centralized , nonp rogram m atic (i.e., m u st be im p lem ented in the stand ard p rod u ct and not requ ire p rogram m ing) andd ynam ic configu ration m anagem ent of TM resou rces inclu d ing hard w are , netw ork, services (single orgrou p ), qu eu e m anagem ent p rioritization ru les, etc.Recovery - The TM m u st have the cap ability to:TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 26 of 130• p ost error cod es to an ap p lication• d etect and term inate long-ru nning transactions based on p red efined tim e-ou t intervalsApplication Transparency - The m essage context(s) that exist betw een the client and server ap p licationp rogram s m u st be m anaged solely by the TM .

The client and server ap p lication p rogram s m u st not ha ve anyknow led ge of the m essage context or the u nd erlying com m u nication m echanism s that su p p ort that context.Comment 1: The follow ing are exam p les of im p lem entations that are non -com p liant w ith the Ap p licationTransp arency requ irem ent.1. Client and server ap p lication p rogram s u se the sam e id entifier (e.g., hand le or p ointer) to m aintain them essage context for m u ltip le transactions.2. Change and / or recom p ilation of the client and / or server ap p lication p rogram s is requ ired w hen thenu m ber of qu eu es or equ ivalent d ata stru ctu res u sed by the TM to m aintain the m essage context betw eenthe client and server ap p lication p rogram s is changed by TM ad m inistra tion.Comment 2: The intent of this clau se is to encou rage the u se of general p u rp ose, com m ercially available transactionm onitors, and to exclu d e sp ecial p u rp ose softw are d evelop ed for benchm ark ing or other lim ited u se.

It isrecognized that im p lem entations of featu res and functionality d escribed above vary across vend ors' architectu res.Su ch d ifferences d o not p reclu d e com p liance w ith the requ irem ents of this clau se.Comment 3: Functionality of TM or equ ivalent softw are is not requ ired if the DBMS m aintains an ind ivid u al contextfor each em u lated u ser.2.3.6Any error that w ou ld resu lt in an invalid TPC-C transaction m u st be d etected and rep orted .

Aninvalid TPC-C transaction inclu d es transactions that, if com m itted , w ou ld violate the level of d atabaseconsistency d efined in Clau se 3.3. These transactions m u st be rolled back. Th e d etection of theseinvalid transactions m u st be rep orted to the u ser as p art of the ou tp u t screen or, in the case of thed eferred p ortion of the d elivery transaction, the d elivery log.Comment 1: Som e exam p les of the typ es of errors w hich cou ld resu lt in an invalid transaction are:Select or u p d ate of a non -existent recordFailu re on insert of a new recordFailu re to d elete an existing recordFailu re on select or u p d ate of an existing recordComment 2: The exact inform ation rep orted w hen an error occu rs is im p lem entation sp ecific and not d efinedbeyond the requ irem ent that an error be rep orted .TPC Benchm ark™C - Stand ard Sp ecification, Revision 5.11 - Page 27 of 1302.4The N ew -Order TransactionThe N ew -Ord er bu siness transaction consists of entering a com p lete ord er throu gh a single d atabase transaction .