Không trả lời, không gợi ý nhưng...góp ý được không anh?

Title là "trắc nghiệm", nghe thì dễ hiểu là "multiple choice" nhưng câu hỏi thì rõ ràng là không phải format này. 

Em xin phép trả lời theo hiểu biết của mình :
a. Đối với hệ cơ sở dữ liệu , tình trạng trên là tình trạng deadlock .
Tưởng tượng chúng ta có 3 table , và 3 user tương ứng với 3 ngả đường và 3 chiếc ô tô trong hình .Trong đó table A một thành phần có quan hệ ràng buộc với table B , table B lại ràng buộc với table C và table C ràng buộc với table A . có 3 user đang write vào 3 table ở các thuộc tính trong 3 bảng tương ứng với 3 chiêc ô tô đã đi được một đoạn (các mũi tên xanh lá cây, xanh da trời và đỏ thể hiện điều này ) cho đến lúc gặp thuộc tính ràng buộc thì writer 1 đang viết vào table A phải viết tiếp ( chiếc xe có mũi tên màu xanh da trời muốn đi tiếp ) những nó phải đợi writer 2 đang viết ở table B hoàn thành công việc (chiếc xe màu xanh lá cây ) nhưng nó phải đợi writer 3 đang viết ở table C hoàn thành công việc . Và writer 3 lại đang đợi writer 1 . Tạo ra một circular waiting dấn tới tình trạng deadlock .
b.Nguyên nhân dẫn tới tình trạng trên là do đặt các tham chiếu A->B, B->C, C->A biện pháp để ngăn chặn là từ lúc thiết kế csdl phải chú ý tới vấn đề này .
c.Đối với bảo mật , tình trạng trên vi phạm nguyên tắc thứ 3 tức là tính availability .Nghĩa là tài nguyên phải được sử dụng bởi các thành phần đã được xác nhận . Việc này dẫn tới tình trạng từ chối dịch vụ (DOS) .
Em trả lời xong rồi, có gì mong mọi người chỉ bào . Cám ơn anh conmale vì câu hỏi  

---> "chú ý" là chú ý thế nào? Đây chưa phải là giải pháp. 

conmale wrote:

---> "chú ý" là chú ý thế nào? Đây chưa phải là giải pháp. 

Đầu tiên là hạn chế việc tạo ra các mối quan hệ ràng buộc chồng chéo như vậy khi thiết kế cơ sở dữ liệu ở bước ban đầu .
Còn giả sử như bắt buộc phải làm như vậy thì tạo ra một phương thức để quản lí việc các writer viết vào các bảng , nghĩa là một khi có một writer đang viết thì tất cả các bảng có liên quan tới bảng đang được viết phải được khóa , chờ đến lúc nào writer viết xong thì mới mở ra để cho các writer khác có thể viết . Em nghĩ có 2 giải pháp như vậy  

Vậy với 3 chiếc xe ở trên, chúng được "lock" và "unlock" tuần tự thế nào để tránh tình trạng "deadlock"?

PS: chúng ta đang dùng "xe" để làm ví dụ cho nên cố gắng dùng "xe" để phân tích, đừng dùng "bảng". 

OK.

Nếu "chấm điểm" một cách dễ dãi ngay lúc này thì điểm sẽ là 6 trên 10.. 

conmale wrote:

OK.

Nếu "chấm điểm" một cách dễ dãi ngay lúc này thì điểm sẽ là 6 trên 10.. 

Vậy là em còn có thể nộp bài khác .Em sẽ cố gắng viết và phân tích kĩ lưỡng để nộp bài khác . Cám ơn anh ! 

H3x4 wrote:

conmale wrote:

OK.

Nếu "chấm điểm" một cách dễ dãi ngay lúc này thì điểm sẽ là 6 trên 10.. 

Vậy là em còn có thể nộp bài khác .Em sẽ cố gắng viết và phân tích kĩ lưỡng để nộp bài khác . Cám ơn anh ! 

Em cho biết em đã rút tỉa được gì trong suốt quá trình nhận câu trắc nghiệm --> đánh giá câu trắc nghiệm --> tìm tòi thông tin --> trả lời --> nhận câu "chấm điểm" trên? 

Thử đi hướng khác xem sao (phân tính dạng trường hợp 1,2,3 như anh conmale nhé!):

Trường hợp 1: MySQL có lệnh LOCK TABLES và UNLOCK TABLES
Mô tả:
- Request 1 được gởi lên, table bị lock (để làm chuyện gì đó); chẳng may request 1 bị kết thúc giữa chừng một cách bất thường, table chưa được unlock
- Request 2,3,4...n gởi lên sau sẽ phải nằm chờ mà không làm gì được vì table giờ đã bị lock cho đến khi MySQL hoặc Application restart.
(có thể đây không phải là 1 ví dụ tốt cho "deadlock" nhưng nó cũng thể hiện được vấn đề là "đợi mãi mà resource không được giải phóng để dùng tiếp").
 

Thực tế:
- Bằng cách đưa vào các dữ liệu "không bình thường", kẻ tấn công có thể làm 1 request "chết" giữa chừng --> table/db thế là bị lock mãi

Khắc phục:
- Open for discussion

Trường hợp 2,3,4: theo hướng trên tìm thêm xem thử?  

Nếu nói như anh nbthanh thì trường hợp như 3 chiếc ô tô ở trên đâu có bao giờ xảy ra được . Ban đầu em cũng không hiểu làm sao có thể xảy ra trường hợp này được , để deadlock thì phải dính vào writer , tức là có thể chia ra làm các trường hợp 1 writer / nhiều table , nhiều writer / nhiều table , nhiều writer / 1 table . Và cái của em nói thuộc loại 3 writer/3 table , mấy trường hợp kia em không biết làm cách nào để nó tạo ra deadlock như trong hình trên cả . Hay là còn trường hợp nào khác thì mấy anh góp ý .
@0xdeadbeef : livelock là sao vậy bạn ? 

H3x4 wrote:

Nếu nói như anh nbthanh thì trường hợp như 3 chiếc ô tô ở trên đâu có bao giờ xảy ra được . Ban đầu em cũng không hiểu làm sao có thể xảy ra trường hợp này được , để deadlock thì phải dính vào writer , tức là có thể chia ra làm các trường hợp 1 writer / nhiều table , nhiều writer / nhiều table , nhiều writer / 1 table . Và cái của em nói thuộc loại 3 writer/3 table , mấy trường hợp kia em không biết làm cách nào để nó tạo ra deadlock như trong hình trên cả . Hay là còn trường hợp nào khác thì mấy anh góp ý .
@0xdeadbeef : livelock là sao vậy bạn ? 

Xảy ra chứ sao không. Giả sử 3 xe tới cùng 1 lúc mà không ai nhường ai thì kẹt liền. Thấy kẹt xe ở SG và Hn không?