คำถามติดแท็ก transaction

หนึ่งในหลักการออกแบบการบริการ SOA หลักคือหลักการบริการการรวมบริการ ( https://en.wikipedia.org/wiki/Service_composability_principle ) แนวคิดก็คือการสร้างบริการใหม่โดยใช้สิ่งที่มีอยู่เป็นหน่วยการสร้างจะสามารถพัฒนาบริการใหม่ได้อย่างรวดเร็ว ชนิดคล้ายกับวิธีที่คุณเรียกวิธีการที่มีอยู่ของวัตถุเมื่อคุณใช้วิธีการใหม่ นี่คือสิ่งที่การเพิ่มประสิทธิภาพการผลิตส่วนใหญ่จาก SOA ควรมาจาก มีคนทำสิ่งนี้จริงๆในทางปฏิบัติหรือไม่? ฉันได้เห็นสิ่งนี้ซ้ำไปซ้ำมาอย่างไม่มีที่สิ้นสุดในข้อความที่เป็นลายลักษณ์อักษร แต่ยังไม่เคยมีประสบการณ์การใช้งานจริงมาใช้ ข้อความส่วนใหญ่ไม่ได้กล่าวถึงการจัดการธุรกรรมใด ๆซึ่งดูเหมือนว่าฉันจะเป็นอุปสรรคที่ใหญ่ที่สุดในการตระหนักถึงบริการที่รวบรวมได้ ก่อนอื่นคุณต้องแก้ไขปัญหาการทำธุรกรรมก่อนที่จะสามารถเขียนบริการที่ไม่สำคัญ แน่นอนถ้าตัวอย่างมีบริการ "findCurrentTime ()" และ "writeLogMessage ()" มันง่ายที่จะไม่กังวลเกี่ยวกับการทำธุรกรรม แต่ไม่เมื่อมีตัวอย่างในโลกแห่งความจริงเช่น "depositMoney ()" และ "drawMoney () " ฉันรู้สองตัวเลือก: ใช้งานธุรกรรมจริงกับ WS-Atomic Transaction หรือ ใช้โซลูชันที่อิงตามค่าตอบแทนซึ่งชดเชยการเรียกไปยัง A ด้วย "CancA ()" หรือ somesuch หากการเรียกไปยัง B ล้มเหลว ทั้งสองอย่างดูมีปัญหามาก / ใกล้จะใช้ไม่ได้กับฉัน: ธุรกรรม …

15 web-services  soa  transaction 

ในการสัมภาษณ์มีคนถามฉัน: เราจะจัดการวิธีการทำธุรกรรม / dao 2 วิธีในการทำธุรกรรมเดียวได้อย่างไร ความสามารถที่ต้องการ: หากทุกคนล้มเหลวเราจำเป็นต้องย้อนกลับทั้งสองวิธี ทั้งสองวิธีสามารถเรียกแยกแนบกับธุรกรรมเดียว การจัดการควรอยู่ในชั้น DAO ไม่ใช่ในชั้นบริการ ฉันคิดว่า: คำถามเกี่ยวข้องกับการจัดการธุรกรรมในฤดูใบไม้ผลิ

12 spring  transaction  service  dao 

เรามีสามชั้นในใบสมัครของเรา ชั้นบริการเพื่อให้ API ภายนอก เลเยอร์ BO สำหรับตรรกะทางธุรกิจของเราและเลเยอร์ DAO สำหรับการเชื่อมต่อฐานข้อมูลของเรา สมมติว่าทุกครั้งที่เราอัปเดตไฟล์เราต้องการเปลี่ยนบางอย่างในโฟลเดอร์เช่น 'วันที่แก้ไขล่าสุด' ต้องทำสิ่งนี้ในการทำธุรกรรม อาจประสบความสำเร็จและทั้งไฟล์และโฟลเดอร์ได้รับการแก้ไข หรือมีความล้มเหลวและธุรกรรมได้รับการย้อนกลับดังนั้นวัตถุทั้งสองอยู่ในสถานะก่อนหน้า "แก้ไขโฟลเดอร์เมื่อไฟล์ได้รับการแก้ไข" - ปฏิกิริยาเป็นตรรกะทางธุรกิจอย่างแท้จริง นี่ก็หมายความว่ามันอยู่ในเลเยอร์ BO อย่างไรก็ตามเราใช้ Objectify สำหรับฐานข้อมูลของเราดังนั้นในการเริ่มต้นธุรกรรมที่เราต้องเรียก ofy (). transact (... ) ถ้าเราเรียกใช้ฟังก์ชันนี้ในเลเยอร์ BO สิ่งนี้จะหยุดการออกแบบของเราเนื่องจากจะมีการเรียกเฉพาะฐานข้อมูล (Objectify) ในชั้นธุรกิจของเรา อะไรจะเป็นทางออกที่สะอาดสำหรับปัญหานี้

11 java  design  design-patterns  transaction 

ใน API ฉันทำงานอยู่มีการดำเนินการลบจำนวนมากซึ่งยอมรับอาร์เรย์ของ ID: ["1000", ..., "2000"] ฉันมีอิสระที่จะใช้การดำเนินการลบตามที่ฉันเห็นสมควรดังนั้นฉันตัดสินใจที่จะทำธุรกรรมทั้งหมด: นั่นคือถ้า ID เดียวไม่ถูกต้องคำขอทั้งหมดล้มเหลว ฉันจะเรียกสิ่งนี้ว่าโหมดเข้มงวด try{ savepoint = conn.setSavepoint(); for(id : IDs) if( !deleteItem(id) ){ conn.rollback(savepoint); sendHttp400AndBeDoneWithIt(); return; } conn.commit(); } ทางเลือก (นำไปใช้ที่อื่นในชุดซอฟต์แวร์ของเรา) คือทำสิ่งที่เราทำได้ในแบ็กเอนด์และรายงานความล้มเหลวในอาเรย์ ส่วนหนึ่งของซอฟต์แวร์นั้นเกี่ยวข้องกับคำขอที่น้อยลงดังนั้นการตอบสนองจึงไม่ได้กลายเป็นอาร์เรย์ขนาดใหญ่ ... ในทางทฤษฎี ข้อผิดพลาดล่าสุดที่เกิดขึ้นในเซิร์ฟเวอร์ที่มีทรัพยากรต่ำทำให้ฉันดูรหัสอีกครั้งและตอนนี้ฉันตั้งคำถามกับการตัดสินใจเดิมของฉัน - แต่คราวนี้ฉันมีแรงจูงใจมากขึ้นตามความต้องการทางธุรกิจมากกว่าแนวทางปฏิบัติที่ดีที่สุด ตัวอย่างเช่นถ้าฉันล้มเหลวในการร้องขอทั้งหมดผู้ใช้จะต้องลองอีกครั้งในขณะที่หากมีการลบรายการจำนวนหนึ่งผู้ใช้สามารถดำเนินการให้เสร็จสิ้นแล้วขอให้ผู้ดูแลระบบทำส่วนที่เหลือ (ในขณะที่ฉันแก้ไขข้อผิดพลาด !) นี่จะเป็นโหมดที่ได้รับอนุญาต ฉันพยายามหาคำแนะนำเกี่ยวกับเรื่องนี้ทางออนไลน์ แต่ฉันกลับมามือเปล่า ดังนั้นฉันมาหาคุณ: สิ่งที่คาดหวังมากที่สุดจากการดำเนินการเป็นจำนวนมากในลักษณะนี้? ฉันควรจะเข้มงวดมากขึ้นหรือฉันควรจะได้รับอนุญาตมากขึ้น?

11 user-experience  application-design  transaction  failure 

ฉันพยายามพัฒนาเครื่องมือการรายงานขนาดเล็ก (พร้อม backend sqlite) ฉันสามารถอธิบายเครื่องมือนี้ในฐานะบัญชีแยกประเภท "ธุรกรรม" ได้ดีที่สุด สิ่งที่ฉันพยายามทำคือติดตาม "การทำธุรกรรม" จากการดึงข้อมูลรายสัปดาห์: "ใหม่" (หรือเพิ่ม) - ทรัพยากรเป็นสิ่งใหม่สำหรับแอปของฉันเนื่องจากแอปของฉันอาจไม่ได้ติดตามทรัพยากรนี้มาก่อนเนื่องจากไม่ได้เห็นผ่านสารสกัด "อัปเดต" (หรือกด) - มีการใช้งานล่าสุดของทรัพยากรนั้นอัปเดตช่วงเวลาการเก็บข้อมูลภายในสัปดาห์อื่น "ลบ" (หรือลดลง) - รายการนี้ไม่เห็นการใช้งานตั้งแต่รายงานล่าสุด (ตัวเลือก แต่จะดีสำหรับการทำกราฟการเปลี่ยนแปลงความต้องการทรัพยากรในแต่ละสัปดาห์ต่อสัปดาห์) ทั้งหมดที่ฉันได้รับคือสารสกัดข้อมูลรายสัปดาห์ (ไฟล์ที่คั่นด้วยไพพ์ไลน์) มาจากระบบเก็บถาวร / จัดการบันทึกแบบดั้งเดิมที่ฉันไม่สามารถควบคุมได้ แต่ละบรรทัดสามารถกลั่นโดยพื้นฐานนี้: resource_id | resource info | customer_id | customer_info ข้อมูลตัวอย่าง: 10| Title X | 1 | Bob 11| Another title | …

9 algorithms  data  transaction  text-processing