Ngăn người dùng làm việc trên cùng hàng

Question

Tôi có một ứng dụng web tại nơi làm việc tương tự như hệ thống làm việc bán vé. Một số người dùng nhập các vấn đề mới. Các công nhân khác chọn và giải quyết các vấn đề. Tất cả dữ liệu được duy trì trong máy chủ MS SQL 2005.

Người dùng làm việc để giải quyết sự cố truy cập trang nơi họ có thể xem các sự cố mở. Bởi vì có tới hai mươi người có thể xem trang này cùng một lúc, một vấn đề tiềm năng mà tôi phải giải quyết là những gì xảy ra nếu ai đó chọn một vấn đề mà người khác đã chọn ngay sau khi tải trang của họ.

Để giải quyết vấn đề này, tôi đã làm hai việc. Đầu tiên, GridView hiển thị các vấn đề cần chọn sử dụng bộ đếm thời gian AJAX để cập nhật mỗi giây. Khi vấn đề đã được chọn, nó sẽ biến mất sau một giây. Trong trường hợp họ chọn một trong vòng thứ hai này, họ nhận được một thông báo yêu cầu họ chọn một cái khác.

Vấn đề là phần AJAX của việc này đang gửi quá nhiều cập nhật (đây là những gì tôi giả định) và nó ảnh hưởng đến hiệu suất của trang và cơ sở dữ liệu. Ngoài ra, các cập nhật không hoạt động mỗi giây. Tôi thấy bộ đếm thời gian không đáng tin cậy khi làm việc để kích hoạt các thủ tục được lưu trữ.

Phải có cách nào tốt hơn, nhưng dường như tôi không thể tìm thấy. Có ai có kinh nghiệm với một tình huống như thế này hoặc có đề xuất để giữ cho nhiều người dùng chọn cùng một bản ghi để duy trì? Tôi thực sự không muốn vô hiệu hóa phần AJAX hoàn toàn bởi vì tôi cảm thấy tin nhắn một mình sẽ làm cho ứng dụng bực bội khi sử dụng.

Xin cảm ơn,

Answer 1

Hai điều có thể giúp giảm thiểu vấn đề của bạn.

Trước tiên, thông báo sau khi chọn là trường hợp đã được thực hiện là cần thiết bất kể khung thời gian cập nhật ajax của bạn.Thậm chí kiểm tra từng giây không có nghĩa là hai người không thể nhấp vào cùng một trường hợp với những gì họ cảm nhận được cùng một lúc. Trong những trường hợp như vậy, một trong những người dùng cần được thông báo rằng lựa chọn của họ không hợp lệ mặc dù nó có vẻ hợp lệ khi được chọn. Thông báo này không cần phải phức tạp; giữ một giai điệu nhẹ nhàng, hữu ích có thể cải thiện nhận thức của người dùng ngay cả trong ánh sáng của sự thất vọng. Và nếu bạn xác định người dùng đã chọn bản ghi đó, điều đó sẽ không chỉ giúp người dùng của bạn phối hợp trong tương lai mà còn chuyển hướng sự chú ý từ chương trình của bạn đến người dùng đã đánh cắp trường hợp ngon ngọt này. (thực sự, quản lý có thể như mang lại cho người dùng của bạn sự cố thường xuyên vì nó sẽ thúc đẩy họ chọn trường hợp nhanh hơn)

Thứ hai, một tinh chỉnh nhỏ về cách bạn hiển thị trường hợp có thể giảm va chạm lựa chọn. Thêm một yếu tố ngẫu nhiên để hiển thị thứ tự và/hoặc lọc ra mọi trường hợp khác trên màn hình sẽ giúp người dùng của bạn chọn các trường hợp khác nhau một cách tự nhiên. Nhận dạng mẫu và lựa chọn tác vụ của con người không thực sự ngẫu nhiên nên những thay đổi nhỏ trong bản trình bày có thể bằng những thay đổi lớn đối với hành vi lựa chọn. Giảm trong cơ hội va chạm giữ thông báo va chạm của bạn hiếm (và do đó ít gây phiền toái cho người dùng của bạn). Điều này thậm chí còn tốt hơn nếu người dùng của bạn có thể được chia thành các phân loại có thể giúp xác định thứ tự/lọc trường hợp hữu ích. Được rồi, một điều thứ ba sẽ giúp bạn theo thời gian là nếu bạn giữ một bản ghi khi va chạm xảy ra (với dữ liệu meta hữu ích về va chạm — như người đã tham gia và chọn thời gian). Được trang bị với dữ liệu va chạm vững chắc, bạn có thể tìm thấy những gì hoạt động và những gì không. Theo thời gian, bạn có thể trau dồi ứng dụng của mình vào các trường hợp sử dụng thực tế cũng như xác định các vấn đề tiềm ẩn sớm. Không có gì trấn an người dùng của bạn nhiều hơn là vấn đề (và có thể giải thích kế hoạch của bạn để giải quyết nó) trước khi họ thậm chí còn biết nó tồn tại.

Với các mẫu giảm nhẹ này, có thể bạn sẽ thấy bạn có thể giảm khung thời gian truy vấn ajax một cách an toàn mà không ảnh hưởng đến trải nghiệm người dùng. Và với tính năng ghi nhật ký hữu ích, bạn sẽ có được sự đảm bảo rằng bất kỳ điều chỉnh nào bạn đưa ra đều thực sự hoạt động (hoặc không phải là —, điều này thậm chí còn hữu ích hơn để biết).

Answer 2

Bạn đã thử tăng thời gian giữa các lần làm mới. Tôi hy vọng rằng một lần trong 30 giây là đủ. 40 yêu cầu/phút là tải ít hơn rất nhiều so với 1200/phút. Người dùng của bạn thậm chí có thể không nhận thấy sự khác biệt.

Nếu có, cách cung cấp nút làm mới trên trang để người dùng có thể làm mới danh sách ngay trước khi chọn một mục để tránh thông báo gây phiền nhiễu nếu họ chọn.

Answer 3

Nếu có thể giới hạn hệ thống để họ chỉ gặp vấn đề mở tiếp theo ngoài hàng đợi công việc thay vì họ có thể chọn từ tất cả các sự cố mở.

Nếu điều đó là không thể, tôi cho rằng bạn có thể kiểm tra khi lựa chọn một vấn đề để xem liệu nó có còn hay không. Nếu nó không có sẵn, sau đó làm cho nó biến mất sau khi người dùng nhấp vào nó. Bằng cách này, bạn chỉ yêu cầu khi họ thực sự nhấp vào một cái gì đó như trái ngược với việc bỏ phiếu liên tục của dữ liệu.

Answer 4

Đặt trường dấu thời gian khóa trên hàng trong cơ sở dữ liệu. Viết một proc được lưu trữ trả về true hoặc false nếu dấu thời gian hết hạn cũ hơn thời gian cụ thể. Đặt các phiên trên ứng dụng web của bạn hết hạn trong cùng một thời điểm, một hoặc hai phút. Khi người dùng chọn một hàng họ nhấn proc được lưu trữ để giúp ứng dụng quyết định xem nó có nên cho phép người dùng sửa đổi nó hay không.

Hy vọng rằng sẽ làm cho tinh thần ....

Answer 5

tôi đã làm một cái gì đó tương tự mà một khi người dùng mở một vé (hàng) nó giao vé đó để người dùng và thiết lập một giá trị được ghi nhận rằng, giống như và FK đó người dùng cụ thể, vì vậy nếu bất kỳ ai khác cố gắng mở vé đó (hàng) nó sẽ cho họ biết rằng nó đã được gán cho người khác.

Answer 6

Tôi bị thiếu để xem sự cố, đặc biệt sau khi bạn đề cập bạn đã gắn cờ vé đang được tiến hành/đang được duy trì và có dấu thời gian/phiên bản của mục.

Không phải là sau đủ:

1. tài duyệt vé và nhìn thấy một danh sách các vé có sẵn ví dụ này không bao gồm những người mà đang ở trong db như cơ bản dở dang. Nếu bạn muốn người dùng cũng nhìn thấy vé đang diễn ra, bạn cho biết rõ ràng trong trạng thái vé và tắt tùy chọn để nhận vé.
2. Người dùng hoặc cờ một vé như đang được tiến hành một cách rõ ràng hoặc ngầm định bằng cách mở vé (tùy thuộc vào trải nghiệm người dùng/cách trình bày của người dùng).
3. dùng di chuyển một cách rõ ràng vé sang trạng thái khác ví dụ hoàn thành, không hợp lệ, chờ phản hồi vv

Khi các mục được lấy ra tại 1, bạn đưa dấu thời gian/phiên bản. Khi 2 xảy ra, bạn sử dụng một cách tiếp cận đồng thời lạc quan để đảm bảo rằng nếu 2 người cố gắng cập nhật việc lấy vé cùng một lúc chỉ có người đầu tiên sẽ thành công.

Điều gì sẽ xảy ra đối với người thứ hai, cập nhật ... ở đâu ... timestamp = @timestamp sẽ không tìm thấy bất kỳ bản ghi nào để cập nhật và bạn sẽ báo cáo lại rằng vé đã được thực hiện.

Nếu bạn muốn, bạn có thể xây dựng trên đầu trang ở trên để cập nhật giao diện người dùng khi vé được lấy.Điều này có thể bằng cách làm mới toàn bộ trang hiện tại của vé sau thời gian x (có thể cảnh báo/nhắc người dùng), hoặc thậm chí bằng cách lấy danh sách vé thay đổi cho trang vé được hiển thị bằng ajax. Bạn vẫn có các bước trước đó tại chỗ, vì điều này sửa đổi nó chỉ là một sự tiện lợi cho người dùng.