การทำธุรกรรมระหว่างบริการเว็บและฐานข้อมูลเป็นไปได้หรือไม่?

ฉันต้องการเรียกใช้บริการเว็บเพื่อแทรกบันทึกลงในฐานข้อมูล จากนั้นฉันต้องการแทรกบันทึกในฐานข้อมูลระยะไกลในเมืองอื่น หากบริการเว็บดำเนินการได้สำเร็จ

นี่คือโค้ดตัวอย่างแบบง่าย:

IdentificationSystem.Service Identify = new IdentificationSystem.Service();
        string result= Identify.InsertWorkshopInfo(BosWorkshop.WpSvUserName, BosWorkshop.WpSvPassword,BosWorkshop.WkIcode,BosWorkshop.WpName)

if (result==0)//If success
 {
   Connect to a remote database and then insert a record 
}

ตามโค้ดตัวอย่างของฉัน จะเกิดอะไรขึ้นหากข้อมูลที่แทรกผ่านบริการเว็บและบริการเว็บกลับมาสำเร็จ แต่ฉันไม่สามารถแทรกบันทึกในฐานข้อมูลระยะไกลในเมืองอื่นได้ บางอย่างเช่นการเชื่อมต่อหลวม

ฉันควรทำอย่างไรดี? ฉันสามารถใช้ System.transaction name space ที่นี่ได้ไหม ฉันกำลังเขียนโค้ดบริการเว็บด้วยตัวเอง


c# asp.net web-services
person Raymond Morphy    schedule 10.07.2011    source แหล่งที่มา
comment
คุณสามารถใช้ System.transaction ได้เนื่องจากสามารถจัดการธุรกรรมแบบกระจายได้   -  person Jayantha Lal Sirisena    schedule 10.07.2011

คำตอบ (2)


arrow_upward
4
arrow_downward

หากเซิร์ฟเวอร์ทั้งสองกำลังเรียกใช้ Distributed Transaction Coordinator (MSDTC) แสดงว่าใช่ ธุรกรรมแบบกระจายก็เป็นไปได้

ธุรกรรม TransactionScope จะเพิ่มขึ้นโดยอัตโนมัติโดยใช้ DTC

แต่คุณควรพิจารณาถึงผลกระทบ: ธุรกรรมที่ใช้เวลานานข้ามเซิร์ฟเวอร์อาจไม่เป็นที่ต้องการ นอกจากนี้ยังมีข้อควรพิจารณาด้านความปลอดภัยและไฟร์วอลล์ด้วย

person Mitch Wheat    schedule 10.07.2011
comment
คุณหมายถึงการเริ่มต้นบริการผู้ประสานงานธุรกรรมแบบกระจายในบริการ windows สำหรับคอมพิวเตอร์ทั้งสองเครื่องหรือไม่ หรือฉันควรทำอย่างอื่น? - person Raymond Morphy; 10.07.2011
comment
ดูโพสต์นี้สำหรับปัญหา: forums.asp.net/ t/1203072.aspx/ - person Mitch Wheat; 10.07.2011
comment
โดยทั่วไป Web Services อาจถูกนำไปใช้ในเทคโนโลยีที่กำหนดเอง ซึ่งอาจไม่รู้อะไรเลยเกี่ยวกับ MS DTC - person djna; 10.07.2011
comment
@Mitch Wheat โปรดให้ข้อเสนอแนะของคุณแก่ฉัน - person Raymond Morphy; 11.07.2011
comment
@ raymond-morphy: ไม่แน่ใจว่าคุณกำลังถามอะไร? - person Mitch Wheat; 11.07.2011
comment
โปรดดูธุรกรรม - person Raymond Morphy; 11.07.2011
comment
@Mitch ความคิดของคุณคืออะไร? กรุณาให้ฉันข้อเสนอแนะของคุณ - person Raymond Morphy; 11.07.2011

arrow_upward
1
arrow_downward

มีมาตรฐาน WS ในการจัดการกับธุรกรรมแบบกระจาย ดูเอกสารนี้ แต่การใช้สิ่งเหล่านั้นต้องการให้ผู้เขียนบริการเว็บควรเลือกที่จะเสนออินเทอร์เฟซที่สอดคล้องกับข้อกำหนดขั้นสูงเหล่านั้น สิ่งนี้เพิ่มความซับซ้อนอย่างมากให้กับการใช้งานและการดูแลระบบบริการเว็บ จึงมีผู้ให้บริการเพียงไม่กี่รายที่เลือกทำเช่นนี้

หากไม่มีการประสานงานธุรกรรมแบบกระจายบางประเภท ความรับผิดชอบต่อความสอดคล้องดังกล่าวจะตกอยู่กับลูกค้า กล่าวคือ คุณ. อย่างมีประสิทธิภาพ คุณต้องเก็บบันทึกที่เชื่อถือได้เกี่ยวกับสิ่งที่คุณต้องการพยายามทำ (ฉันต้องแทรก สิ่งนี้ ที่นี่ และ สิ่งนั้น ที่นั่น) จากนั้นจึงใช้กลไกบางอย่างเพื่อรับมือกับความล้มเหลว เช่น การลองอีกครั้งในอนาคต หรือยกเลิกการแทรกครั้งแรกหากการแทรกที่สองเป็นไปไม่ได้

ผลิตภัณฑ์ "การออกแบบท่าเต้นตามกระบวนการ" ต่างๆ พยายามทำให้การเข้ารหัสกฎดังกล่าวง่ายขึ้น แต่นี่เป็นปัญหาที่ยากมากที่จะแก้ไขให้สมบูรณ์ เพื่อยกตัวอย่าง:

  • ทุกบริการที่คุณใช้ต้องมีความสามารถในการเลิกทำบางอย่าง บริการบางอย่าง (เช่น ส่งอีเมล) ไม่มีการเลิกทำตามธรรมชาติ อื่นๆ มีค่าใช้จ่ายทางการเงินในการเลิกทำ (เช่น การยกเลิกการจองอาจต้องใช้เงินมัดจำ) ที่แย่กว่านั้นคือผู้ให้บริการบางรายไม่มีความสามารถในการเลิกทำ
  • คุณไม่ทราบเสมอไปว่าการดำเนินการเสร็จสิ้นแล้วจริงหรือไม่ คุณส่งคำขอ จากนั้นคุณล้มเหลวและไม่เห็นการตอบกลับ ตอนนี้คุณลองอีกครั้งและเสี่ยงที่จะ (พูด) เดบิตสองเท่าหรือไม่? ตามหลักการแล้ว ผู้เขียนบริการจะจัดเตรียมบริการ idempotent (บริการที่สามารถจัดการกับคำขอซ้ำๆ สำหรับการดำเนินการเดียวกันได้อย่างปลอดภัย) และ/หรือความสามารถในการสืบค้นบางอย่างที่ช่วยให้คุณค้นพบชะตากรรมของคำขอได้

ความคิดทั่วไปของฉันคือคุณต้องขึ้นอยู่กับผู้ให้บริการของคุณเพื่อให้บริการที่ช่วยให้คุณสามารถ "เขียน" ฟังก์ชันการอัพเดตหลายรายการที่คุณต้องการได้ หากคุณโชคร้ายมาก สิ่งที่คุณต้องการทำอาจเป็นไปไม่ได้ จากนั้นคุณถอยกลับไปแก้ไขด้วยตนเองสำหรับสถานการณ์ความล้มเหลวบางอย่าง ธุรกิจในโลกแห่งความเป็นจริงทำสิ่งนั้นได้มากมายจริงๆ ผู้คนรับโทรศัพท์เพื่อพิจารณาว่าเกิดอะไรขึ้น เพื่อปรับเปลี่ยนคำสั่งซื้อ หรือแม้แต่ขอให้ยกเลิกคำสั่งซื้อ หากโอกาสที่จะเกิดความล้มเหลวมีน้อย นี่อาจเป็นแนวทางที่คุ้มค่ากว่าในการพัฒนาระบบกันกระสุน

person djna    schedule 10.07.2011