Viết mã thú vị với các API FileNet P8 của IBM, Phần 3 potx

Viết mã thú vị với các API FileNet P8 của IBM, Phần 3: Lấy một số
Triển khai thực hiện một bộ phân phối số thứ tự trong FileNet P8
Bill Carpenter, Kiến trúc sư phần mềm ECM, IBM
Tóm tắt: Vâng, bạn cũng có thể có một hiệu bánh ở góc phố dựa vào ECM với
một hàng đợi khách hàng có trật tự! Để mua bánh cần lấy một số thứ tự. Bài viết
này bàn về các kỹ thuật triển khai thực hiện để nhận các số thứ tự tin cậy duy nhất
từ một kho lưu trữ IBM® FileNet® P8. Một số trong các cách tiếp cận hiển nhiên
đã ẩn giấu các mối nguy hiểm, nhưng có một cách tiếp cận đúng và có ích là đơn
giản và hiệu năng. Cùng với cách giải quyết vấn đề chung này, chúng ta sẽ thấy
một số vấn đề về phát triển P8 có quy mô lớn hơn nhiều.
Mở đầu
Thói quen ở nhiều nơi có các cửa hàng nhỏ là nắm được các khách hàng đã xếp
hàng bằng cách gán cho họ các số thứ tự sát với thứ tự mà họ tới cửa hàng. Các số
thứ tự này thường được in trên các mảnh giấy nhỏ và được phân phối từ một bộ
phân phối cơ khí vật lý duy nhất. Nếu có nhiều khách hàng đến đồng thời, mối
quan hệ này dễ dàng bị phá vỡ bởi phép xã giao và phép lịch sự thông thường.
TỪ CHỐI BẢO HÀNH
Mã đi kèm là mã ví dụ do Tập đoàn IBM tạo ra. Mã ví dụ này không phải là một
phần của bất kỳ tiêu chuẩn hay sản phẩm nào của IBM và được cung cấp cho bạn
chỉ với mục đích giúp bạn trong việc phát triển các ứng dụng của mình. Mã này
được quy định "như nó vốn có", không bảo hành bất kỳ loại nào. IBM không chịu
trách nhiệm về mọi thiệt hại phát sinh do việc bạn sử dụng mã ví dụ này, ngay cả
khi bạn đã được biết về khả năng thiệt hại như vậy.
Các vấn đề tương tự thường phát sinh trong các hệ thống phần mềm. Một hệ thống
thường cần gán các số cho các việc nào đó với đảm bảo rằng các số đó là duy nhất
và theo một số mô hình. Có một số giải pháp chung cho vấn đề này, nhưng các hệ
thống phân phối làm phức tạp các vấn đề. Hầu như không chắc rằng bạn sẽ sử
dụng một hệ thống ECM để gán các số cho các khách hàng tại một hiệu bánh ở
góc phố. (Nhưng nếu bạn đã quan tâm về điều đó, tôi có thể nối bạn với một người
bán hàng có thiện ý!) Tuy nhiên, bạn có thể cần gán các số theo trường hợp hoặc
các số mã định danh (ID) khách hàng hoặc các số bộ phận hoặc một cái gì đó đơn

giản hơn. Các nhà cung cấp cơ sở dữ liệu triển khai thực hiện các kiểu cột số thứ
tự chỉ dùng cho loại vấn đề này. Tuy nhiên, P8 không cung cấp truy cập trực tiếp
vào các kiểu số thứ tự cơ sở dữ liệu, vì vậy bạn phải sử dụng các cơ chế khác.
Trong bài này, chúng ta sẽ việc xem xét cách giải quyết vấn đề này trong một môi
trường P8. Hãy tóm tắt các yêu cầu:
1. Chúng ta cần gán các số được bảo đảm tuyệt đối là duy nhất. Hoàn toàn
không chấp nhận gán hai lần với cùng một số.
2. Chúng ta muốn các số đi theo một vài mô hình. Chúng ta không muốn có
những cách quãng trong việc gán số. Mô hình có thể có nhiều thứ, nhưng
với các mục đích của mình chúng ta sẽ chỉ sử dụng mô hình tăng dần đơn
giản. Số tiếp theo mà chúng ta nhận được sẽ là một số lớn hơn số đứng
trước.
3. Chúng ta muốn tất cả điều này hoạt động tin cậy và có hiệu năng tốt trong
một môi trường P8 có nhiều luồng, nhiều bộ xử lý, nhiều máy chủ, nhiều
tầng và nhiều người dùng.
4. Trong khi chúng ta đang ở đó, chúng ta cần khoảng một chục bánh nướng
nhỏ màu đỏ trông rất ngon có lớp phủ kem pho mát!
Trước khi mô tả việc triển khai thực hiện ưa thích của mình, đầu tiên chúng ta sẽ
xem xét một vài kỹ thuật hoặc không làm việc hoặc không làm việc rất tốt. Ngay
cả khi bạn chưa bao giờ có nhu cầu triển khai thực hiện trường hợp sử dụng cụ thể
này, hầu hết các điểm được minh họa trong bài này có thể áp dụng cho nhiều lĩnh
vực lập trình P8.


Đồng bộ Java hay .NET
Nếu bạn là người mới đến với công việc phát triển doanh nghiệp hay phát triển
phân phối nói chung, bạn có thể nghĩ ngay đến việc sử dụng một đối tượng đơn lẻ
có một số kiểu truy cập đồng bộ hóa đến phần cập nhật bộ đếm. Trong Java, đó sẽ
là một phương thức synchronized (đã đồng bộ) hoặc khối mã. Trong C#, sẽ là một
phương thức đánh dấu là đã đồng bộ hoặc một khối mã được bảo vệ bằng một

lock(). Các vùng mã có truy cập đồng bộ đôi khi được gọi là các phần tới hạn. Liệt
kê 1 cho thấy một trong nhiều cách để thực hiện điều này.

Liệt kê 1. Khối mã đồng bộ

/**
* *** DON'T DO IT THIS WAY ***
*/
public class Dispenser
{
/** static access only, so private constructor */
private Dispenser() {}
private static int counter = 0;
public static final synchronized int getNextValue()
{
return ++counter;
}
}

Việc sử dụng mã đồng bộ là tốt cho các vấn đề cụ thể, nhưng với trường hợp sử
dụng của chúng ta các nhược điểm là khá rõ. Vì giá trị của bộ đếm chỉ tồn tại trong
bộ nhớ của chương trình đang chạy, nên các giá trị này sẽ bắt đầu lại khi chương
trình được khởi động lại. Bạn có thể thay đổi lớp Dispenser (Bộ phân phối) để lưu
các giá trị đã cập nhật vào một tệp, nhưng điều đó sẽ dẫn đến các vấn đề mới do
không thể phối hợp đồng bộ qua các ranh giới của quá trình. Các ứng dụng chạy
độc lập khác nhau (hoặc các bản sao của cùng một ứng dụng), ngay cả khi chúng
đang sử dụng lớp Dispenser, có thể đã xen kẽ đọc và viết vào tệp. Tệ hơn nữa,
chúng có thể đang truy cập vào một tệp có cùng tên trên các máy tính khác nhau.
Cả hai tình huống đó đều dẫn đến các điều kiện vi phạm các yêu cầu của trường
hợp sử dụng của chúng ta.

Dưới đây là một ví dụ về những rắc rối có thể do các việc đọc và viết xen kẽ. Giả
sử giá trị hiện tại được ghi trong tệp là 7 và sau đó các việc sau đây diễn ra:
 A đọc giá trị 7 từ tệp này.
 B đọc giá trị 7 từ tệp này.
 A viết giá trị 8 vào tệp này.
 C đọc giá trị 8 từ tệp này.
 C viết giá trị 9 vào tệp này.
 B viết giá trị 8 vào tệp này.
Lúc này, cả hai A và B có cùng một số mà họ tin là duy nhất với họ. Người đọc
tệp tiếp theo sẽ kết thúc bằng một giá trị giống như C đã có. Bạn có thể có một vài
ý tưởng về việc sử dụng khóa tệp hoặc các thủ thuật cụ thể của hệ điều hành khác
để đồng bộ hóa truy cập vào một tệp trong một môi trường phân phối. Tuy nhiên,
những khó khăn với kiểu giải pháp đó cũng khá dễ hiểu trong hầu hết ngành khoa
học máy tính và quả là rất khó khăn để nhận diện chính xác nó, do đó, chúng ta
không cần chỉ trích kịch bản này quá nhiều. Nếu bạn cần có sức thuyết phục hơn,
hãy sử dụng máy tìm kiếm ưa thích của mình để nghiên cứu "vấn đề khóa NFS".


Đối tượng bộ phân phối P8
Sử dụng một servlet J2EE
Việc mô tả nó đầy đủ nằm ngoài phạm vi của bài viết này, nhưng có thể sử dụng
an toàn khai báo của J2EE để cung cấp truy cập superuser có kiểm soát tới một
đối tượng P8. Kỹ thuật đó có thể làm việc với cả hai máy khách Java và .NET.
Tóm lại, bạn cần tạo ra một servlet đơn giản để triển khai thực hiện các kỹ thuật
được thảo luận trong phần này. Điều này có thể được thực hiện như một dịch vụ
web hoặc một cái gì đó tương tự miễn là nó trả về giá trị bộ đếm cho người gọi để
sử dụng theo một số định dạng dễ dùng.
Bộ mô tả triển khai cho một servlet J2EE cung cấp đặc tả của một vai trò RunAs
gián tiếp chỉ định một người ủy thác an toàn. Các cuộc gọi J2EE hướng xuống
(bao gồm các cuộc gọi P8 bằng cách sử dụng truyền tải EJB) được thực hiện bằng

nhận dạng an toàn của người ủy thác an toàn đã định. Trong trường hợp của chúng
ta, đó sẽ là một người dùng có các quyền truy cập thích hợp tới đối tượng của bộ
phân phối bị khóa hướng xuống. Ngay cả khi nhận dạng an toàn được cấu hình đã
là một người dùng có đặc quyền khá cao, thì kỹ thuật này là an toàn vì servlet
kiểm soát chặt chẽ những hoạt động nào được phép. Tuy nhiên, kỹ thuật này vì lẽ
đó trở nên kém an toàn hơn do sự phức tạp của servlet đang tăng lên.
Không chỉ kỹ thuật này phân tách các khía cạnh truy cập an toàn, nhưng hiệu quả
một hướng thú vị của việc sử dụng servlet là nó cách ly logic nghiệp vụ của việc
nhận một số thứ tự. Bất kỳ số lượng máy khách tạp nham nào với bất kỳ số lượng
các ngăn xếp công nghệ đều có thể truy cập servlet và nhận được một số thứ tự.
Bất lợi rõ ràng là sự phức tạp của việc thêm servlet vào kiến trúc đó và đưa ra việc
thăm dò máy khách để truy cập nó trong suốt. Cho dù bất lợi đó là đáng kể thì nó
vẫn phụ thuộc vào các đặc điểm kịch bản của bạn.
Một giải pháp phổ biến cho những vấn đề này là sử dụng một cơ sở dữ liệu để duy
trì bộ phân phối. Các cơ sở dữ liệu quan hệ có sẵn cho doanh nghiệp vốn đã phân
phối tài nguyên với ngữ nghĩa khóa tin cậy. Trong kiến trúc P8, các ứng dụng
không thể truy cập trực tiếp vào các cơ sở dữ liệu phía sau. Nói cách khác, việc
truy cập cơ sở dữ liệu phải được bố trí riêng cho các ứng dụng này, cho dù nó
thông qua các nguồn dữ liệu J2EE, nhằm vào các kết nối JDBC, hoặc các phương
tiện khác. Việc này có thể làm việc tốt trong một số kịch bản, nhưng nói chung
thật là phiền toái để làm việc này chỉ để truy cập dữ liệu bộ phân phối.
Một điều mà chúng ta biết là tất cả các ứng dụng dựa vào P8 có quyền truy cập
đến ObjectStores và các đối tượng P8, phải chịu các sự kiểm tra truy cập do P8 bắt
buộc. Do đó chúng ta có thể mô hình hóa bộ phân phối như là một đối tượng P8.
Cụ thể, chúng ta có thể tạo ra một cá thể của một lớp con của CustomObject gọi là
WjcDispenser với một đặc tính tùy chỉnh số nguyên được gọi là WjcCounter. (Gắn
cho các tên tiền tố tùy ý "Wjc" này để tránh các xung đột với tên lớp và tên thuộc
tính khác). Hình 1 cho thấy một biểu đồ UML cho lớp con đơn giản này.

Hình 1. Biểu đồ UML cho WjcDispenser

Chúng ta giả định rằng truy cập an toàn đến đối tượng này có thể được bố trí thuận
tiện cho tất cả người dùng của tất cả các ứng dụng cần sử dụng nó. Bây giờ, chúng
ta sẽ giả định rằng bất cứ ai cũng có thể kết nối tới ObjectStore và cập nhật đối
tượng bộ phân phối. Xem thanh bên Sử dụng một servlet J2EE để có một cách tiếp
cận thú vị tới tình huống an toàn này.
Hơn nữa, chúng ta sẽ che đậy việc tạo đối tượng bộ phân phối ban đầu. Một kỹ
thuật tốt sẽ là có các lớp Java và .NET kèm theo để phát hiện xem đối tượng bộ
phân phối có còn thiếu không và tạo nó theo yêu cầu hoặc trong bộ khởi tạo tĩnh
cho lớp đó. Hai kỹ thuật phổ biến để định vị đối tượng bộ phân phối là sử dụng
một giá trị ID được định sẵn hoặc để lưu trữ đối tượng này trong một đường dẫn
được định sẵn trong ObjectStore. Cũng có thể sử dụng một truy vấn để tìm ra tất
cả các cá thể của lớp WjcDispenser. Với các ví dụ tiếp theo, chúng ta giả định
rằng việc nhận dạng ObjectStore và vị trí cụ thể của đối tượng bộ phân phối dù thế
nào đi nữa cũng được cấu hình cho ứng dụng này.


Các khóa hợp tác của Máy nội dung (CE) FileNet
Khi sử dụng một đối tượng bộ phân phối dựa trên P8, ý tưởng dựa trên khái niệm
để nhận được một số thứ tự là giống nhau: đọc giá trị cũ, cập nhật và lưu giá trị
mới và trả về giá trị mới cho người gọi. Rõ ràng, các quá trình thực hiện cụ thể
thay đổi. Tất cả các nhược điểm về đồng bộ hóa Java hoặc .NET vẫn tiếp tục áp
dụng.
Máy chủ CE và các API triển khai thực hiện một tính năng gọi là khóa hợp tác.
Tính năng này ban đầu được triển khai thực hiện để cung cấp ngữ nghĩa khóa hợp
tác tương thích với RFC-2518 (WebDAV). Các lớp API cho Folder (Thư mục),
Document (Tài liệu) và CustomObject (Đối tượng tùy chỉnh) có các phương thức
để khóa và mở khóa các đối tượng đó. Vì đây là một tính năng P8 tích hợp sẵn
được triển khai thực hiện tại máy chủ, nên bạn có thể phát triển một việc thực hiện
tương tự như những gì được thể hiện trong Liệt kê 2. Ví dụ này cho thấy một

phương thức nội bộ và giả định một số đoạn mã khác đã nhận biết đối tượng bộ
phân phối.

Liệt kê 2. Khóa hợp tác P8

private static final String COUNTER_PROPERTY_NAME = "WjcCounter";
/**
* *** DON'T DO IT THIS WAY ***
*/
private static int getNextValue(CustomObject dispenser)
{
final Properties dispenserProperties = dispenser.getProperties();
// Object might be locked by someone else, so try a few times
for (int attemptNumber=0; attemptNumber<10; ++attemptNumber)
{
dispenser.lock(15, null); // LOCK the object for 15 seconds
try
{
// Because we use a refreshing save, the counter property
// value will be returned.
dispenser.save(RefreshMode.REFRESH); // R/T
break;
}
catch (EngineRuntimeException ere)
{
ExceptionCode ec = ere.getExceptionCode();
if (ec != ExceptionCode.E_OBJECT_LOCKED)
{
// If we get an exception for any reason other than
// the object already being locked, rethrow it.

throw ere;
}
// already locked; try again after a little sleep
try
{
Thread.sleep(100); // milliseconds
}
catch (InterruptedException e) { /* don't worry about this rarity */ }
continue;
}
}
int oldValue =
dispenserProperties.getInteger32Value(COUNTER_PROPERTY_NAME);
int newValue = oldValue + 1;
dispenserProperties.putValue(COUNTER_PROPERTY_NAME, newValue);
dispenser.unlock(); // UNLOCK the object
dispenser.save(RefreshMode.NO_REFRESH); // R/T
return newValue;
}

Giả sử rằng đối tượng bộ phân phối được khởi tạo theo cách không tìm nạp (có
nghĩa là, thông qua một phương thức Factory.CustomObject.getInstance()), kỹ
thuật này trị giá một chuyến đi khứ hồi đến máy chủ CE để áp dụng khóa và tìm
nạp giá trị thuộc tính hiện tại. Nếu đối tượng đã bị khóa, chúng ta sẽ không nhận
được giá trị hiện tại, vì vậy chúng ta lặp lại một vài lần để nhận được thay đổi của
mình lúc khóa bộ phân phối. Nó trị giá một chuyến đi khứ hồi khác đến máy chủ
CE để lưu trữ giá trị bộ đếm mới. Đó là một chi phí hiệu năng hợp lý cho điều này
và cũng hợp lý cho việc sử dụng toàn bộ tính năng khóa/mở khóa.
Vấn đề chính của việc sử dụng khóa hợp tác P8 cho trường hợp sử dụng này là nó
chỉ là khóa hợp tác. Máy chủ CE sẽ không ngăn cấm bất kỳ thay đổi nào do chỉ là

sự hiện diện của một khóa. Lạc quan là, bạn có thể giả định rằng tất cả các ứng
dụng sẽ đi theo trình tự khóa hợp tác. Thực tế, bạn vẫn phải tính đến khả năng các
lỗi ứng dụng bỏ qua việc khóa. Thật dễ dàng để tưởng tượng ai đó viết một đoạn
mã độc lập sử dụng đối tượng bộ phân phối nhưng bỏ qua thực hiện việc khóa.


Gắn với trình xử lý sự kiện
Đó là một lưu ý một phía, nhưng nếu bạn xem cuộc thảo luận về khóa hợp tác
trong phần trước, bạn thấy rằng phải mất ít nhất hai chuyến đi khứ hồi đến máy
chủ để chắc chắn có được một số thứ tự. Có thể thực hiện nó chỉ với một chuyến
đi khứ hồi không? Để thực hiện ý tưởng đó, chúng ta sẽ cần ít nhất một phần tính
toán được thực hiện trên máy chủ CE. Cơ chế CE cho điều đó là các trình xử lý sự
kiện. Dưới đây là một thử nghiệm tư duy:
 Khởi tạo theo cách không tìm nạp đối tượng bộ phân phối (không có
chuyến đi khứ hồi).
 Chúng ta cần phải thực hiện một số kiểu thay đổi cho đối tượng bộ phân
phối sao cho một sự kiện sẽ được bắt đầu. CE có một tính năng cho phép
bạn định nghĩa các sự kiện tùy chỉnh. Trên thực tế, lớp này được gọi là
CustomEvent. Như là một phần của việc thiết lập một lần cho tất cả những
điều này, hãy định nghĩa một sự kiện tùy chỉnh mới và duy trì nó trong
ObjectStore đang giữ đối tượng bộ phân phối.
 Thay vì đưa ra như là một hiệu ứng phụ của một cái gì đó khác, một sự kiện
tùy chỉnh được kích hoạt khi bất kỳ ai gọi phương thức raiseEvent() trên
một đối tượng đăng ký được. Trên máy chủ, việc xử lý đăng ký và sự kiện
cũng giống như với các sự kiện do hệ thống định nghĩa. Hãy gọi
raiseEvent() trên đối tượng bộ phân phối và sau đó gọi save() có làm mới
(để có được giá trị hiện tại của WjcCounter).
 save() sẽ kích hoạt CustomEvent.
 Như là một phần của việc thiết lập một lần, hãy cung cấp một trình xử lý sự
kiện được đăng ký với kiểu CustomEvent cụ thể đó trên cá thể hoặc lớp

WjcDispenser. Trình xử lý sự kiện sẽ tính toán và lưu các giá trị mới cho
đặc tính WjcCounter. Do không thể cập nhật các đặc tính trong một trình
xử lý sự kiện đồng bộ, nên chúng ta sẽ thực hiện trình xử lý sự kiện không
đồng bộ (đồng bộ hoặc không đồng bộ được quy định lúc đăng ký).
 Ứng dụng khách biết cách trình xử lý sự kiện sẽ cập nhật WjcCounter, vì
thế, nó thực hiện một tính toán tương tự để dự báo giá trị mới của
WjcCounter.
Trong thử nghiệm tư duy này, bạn tính rằng các cập nhật cho đối tượng bộ phân
phối sẽ xảy ra một lần tại một thời điểm, cho dù có bao nhiêu ứng dụng khách độc
lập đang yêu cầu nó đi nữa. Máy chủ CE thì không "tối ưu hóa ngay" các cập nhật
trung gian (dự phòng). Bạn hãy nhớ rằng cần bảo đảm các trình xử lý sự kiện
không đồng bộ được thực hiện. Trên thực tế, bạn thậm chí có thể nhớ là đã nghe ở
đâu đó rằng các trình xử lý sự kiện không đồng bộ được xử lý qua hàng đợi (đó là
đúng). Tất cả điều đó dường như thêm vào một cập nhật duy nhất, tin cậy và dự
báo được tới WjcCounter cho mỗi chuyến đi khứ hồi của máy khách đến máy chủ
CE.
Bạn có thể đã đoán được từ giọng điệu mô tả ở trên là có một số vấn đề bí mật ở
đây. Trên thực tế, có hai vấn đề. Thứ nhất, có một khoảng thời gian ngắn giữa việc
cập nhật đối tượng bộ phân phối trong ObjectStore và việc thực hiện trình xử lý sự
kiện không đồng bộ. Nếu có nhiều máy khách độc lập tình cờ thực hiện cấp nhật
cùng một lúc, thì tất cả chúng sẽ thấy cùng một giá trị được làm mới của
WjcCounter và tính toán giá trị cập nhật giống nhau. Thậm chí nếu bạn có thể
khắc phục điều đó và bằng cách nào đó buộc các hoạt động save() của máy khách
cụ thể vào khởi động cụ thể trình xử lý sự kiện, thì sẽ có một vấn đề thứ hai. Vấn
đề thứ hai là mặc dù các sự kiện không đồng bộ được xử lý thực sự thông qua một
hàng đợi, cần có nhiều thiết bị đọc hàng đợi. Vì vậy, không có gì bảo đảm rằng
các trình xử lý sự kiện không đồng bộ sẽ thực hiện theo thứ tự giống như các cập
nhật thực hiện nhanh.

Người viết đầu tiên sẽ thắng
Máy chủ CE có một tính năng tích hợp sẵn để phát hiện tin cậy các cập nhật xen
kẽ. CE triển khai thực hiện một chính sách gọi là người viết đầu tiên sẽ thắng.
Điều đó có nghĩa rằng nếu có hai yêu cầu đang cập nhật cùng một đối tượng, yêu
cầu đầu tiên sẽ thành công còn yêu cầu thứ hai sẽ thất bại. Với việc cập nhật thất
bại này, máy chủ sẽ đưa ra một EngineRuntimeException với một ExceptionCode
của E_OBJECT_MODIFIED. Thông báo ngoại lệ đi kèm là "Đối tượng đã
được sửa đổi vì nó đã được lấy ra". Thế điều đó có nghĩa gì?
Mỗi đối tượng có thể tồn tại độc lập trong một ObjectStore được đánh dấu bằng
một Số thứ tự cập nhật (USN - Update Sequence Number). Đây không phải là một
đặc tính theo nghĩa thông thường, nhưng giá trị của nó được trưng ra qua phương
thức IndependentlyPersistableObject.getUpdateSequenceNumber(). Máy chủ CE
tự động gia tăng USN bất cứ khi nào một đối tượng được cập nhật trong
ObjectStore. Khi bạn tìm nạp một đối tượng từ máy chủ, USN cũng được tìm nạp
và được đưa đến phía máy khách. Các API gửi USN đó trở về máy chủ như là một
phần của đối tượng save(). Nếu giá trị USN đã gửi đi không khớp với giá trị USN
hiện tại đã có trong kho lưu trữ, thì máy chủ CE biết rằng đã có một sự thay đổi
xảy ra (bởi một số người gọi khác) kể từ khi đối tượng này đã được tìm nạp. Điều
này biểu thị một dạng đơn giản của cái mà thế giới cơ sở dữ liệu gọi là khóa lạc
quan.
Cụ thể là máy chủ CE phát hiện những thay đổi xen kẽ này, đó là logic để khai
thác điều đó hơn là tính năng khóa hợp tác tự nguyện hoàn toàn. Thông qua các
API của CE, bạn có thể sử dụng một cái gì đó gọi là khởi tạo không tìm nạp
(fetchless instantiation), mà chúng ta đã đề cập ở đâu đó, để bỏ qua việc kiểm tra
máy chủ, nhưng bạn phải thoát khỏi cách làm việc đó của mình với trường hợp sử
dụng này. Khi bạn khởi tạo tại chỗ một đối tượng trong API mà không cần tìm nạp
nó từ máy chủ, thì đó chính là khởi tạo không tìm nạp. Trong trường hợp này, giá
trị USN có một giá trị đặc biệt để báo hiệu cho máy chủ CE biết bỏ qua việc kiểm
tra USN. Điều này đôi khi được gọi là một cập nhật không được bảo vệ. Nếu sau
đó bạn tìm nạp hay làm mới bất kỳ đặc tính nào từ máy chủ, thì cũng thu được

USN hiện tại.
Tuy nhiên, trong trường hợp sử dụng của chúng ta, để thực hiện khởi tạo không
tìm nạp tiếp theo bằng một cập nhật không được bảo vệ thì chẳng ý nghĩa gì với
một ai đó. Để nhận giá trị hiện tại của đặc tính bộ đếm, dù cách nào đi nữa cũng
phải tìm nạp nó từ máy chủ. Sẽ có khả năng cho một ai đó làm hỏng một cách ác ý
đặc tính bộ đếm thông qua một cập nhật không được bảo vệ, trừ phi những người
cùng tham gia có ác ý ấy đã có thể làm điều tương tự với một chu kỳ cập nhật bình
thường. Vì vậy, không có nguy hiểm mới nào ở đây. Do ngữ nghĩa của trường hợp
sử dụng này, nên lợi thế này là thấp đối với một ai đó làm điều này thông qua một
lỗi mã hóa.
Để tận dụng lợi thế của việc kiểm tra USN và chính sách người viết-đầu tiên- sẽ
thắng của máy chủ CE, bạn cần cố gắng cập nhật bộ đếm trong đối tượng bộ phân
phối này và phát hiện lỗi được ghi lại với một thay đổi xen kẽ. Liệt kê 3 cho thấy
một ví dụ về cách làm điều này.

Liệt kê 3. Người viết đầu tiên sẽ thắng

private static final String COUNTER_PROPERTY_NAME = "WjcCounter";
/**
* This property filter is used to minimize data returned in fetches and refreshes.
*/
private static final PropertyFilter PF_COUNTER = new PropertyFilter();
static
{
PF_COUNTER.addIncludeProperty(1, null, null,
COUNTER_PROPERTY_NAME, null);
}

/**
* Get the next value efficiently by exploiting First Writer Wins

*/
public int getNextValue(boolean feelingUnlucky)
{
final Properties dispenserProperties = dispenser.getProperties();
// Object might be updated by someone else, so try a few times
for (int attemptNumber=0; attemptNumber<10; ++attemptNumber)
{
// If cached data invalid, fetch the current value
// from the server. This also covers the fetchless
// instantiation case.
if (feelingUnlucky
|| dispenser.getUpdateSequenceNumber() == null
|| !dispenserProperties.isPropertyPresent(COUNTER_PROPERTY_NAME))

{
// fetchProperties will fail if the USN doesn't match, so null it out
dispenser.setUpdateSequenceNumber(null);
dispenser.fetchProperties(PF_COUNTER); // R/T
}
int oldValue =
dispenserProperties.getInteger32Value(COUNTER_PROPERTY_NAME);
int newValue = oldValue + 1;
dispenserProperties.putValue(COUNTER_PROPERTY_NAME, newValue);

try
{
// Because we use a refreshing save, the counter property's
// new value will be returned from the server.
dispenser.save(RefreshMode.REFRESH, PF_COUNTER); // R/T
return newValue;

}
catch (EngineRuntimeException ere)
{
ExceptionCode ec = ere.getExceptionCode();
if (ec != ExceptionCode.E_OBJECT_MODIFIED)
{
// If we get an exception for any reason other than
// the object being concurrently modified, rethrow it.
throw ere;
}
// Someone else modified it. Invalidate our cached data and try again.
dispenser.setUpdateSequenceNumber(null);

dispenserProperties.removeFromCache(COUNTER_PROPERTY_NAME);
continue;
}
}
// too many iterations without success
throw new RuntimeException("Oops");
}

/**
* Set by constructor or some other means.
* Fetchless instantiation is OK.
*/
private final CustomObject dispenser;

Thoạt nhìn, điều này dường như có hai chuyến đi khứ hồi giống nhau của máy chủ
như mã khóa hợp tác nêu trên của chúng ta. Điều đó đúng với việc cập nhật bộ
đếm đầu tiên. Chúng ta phải tìm nạp giá trị bộ đếm hiện tại từ máy chủ, nhưng nên

nhớ trạng thái bộ đếm sau một cập nhật thành công. Nếu không có ai khác đã cập
nhật đối tượng bộ phân phối vào lúc này, thì các cập nhật cuối của chúng ta sẽ chỉ
trả tiền cho một chuyến đi khứ hồi. Mặt khác, nếu một cặp ứng dụng đang thay đổi
việc cập nhật bộ phân phối này, thì có lẽ như một số loại cân bằng tải, trạng thái đã
nhớ đó gây tác dụng ngược với chúng ta. Trong trường hợp đó, sẽ luôn trả tiền cho
ba chuyến đi khứ hồi để thực hiện một cập nhật (cố gắng cập nhật đã thất bại ban
đầu, tìm nạp giá trị bộ đếm hiện tại và cập nhật thành công cuối cùng). Chi phí
phát sinh này phải chịu thêm ngay cả khi các ứng dụng cạnh tranh đang thực hiện
các cập nhật với nhiều loại thời gian khác nhau giữa chúng (ví dụ, A nhận được
một giá trị bộ đếm trên cơ sở một giờ còn B nhận được một giá trị bộ đếm trên cơ
sở nửa giờ). Liệu bạn sẽ phải trả chi phí thêm hay không tùy thuộc vào việc bạn có
bao nhiều ứng dụng đọc độc lập, chúng chồng chéo lên nhau như thế nào và v.v.
Tham số Boolean feelingUnlucky điều khiển phương thức trả chi phí cho một
trình tự cập nhật hai chuyển đi khứ hồi hay đặt cược vào trình tự cập nhật một-
hoặc-ba chuyển đi khứ hồi.


Các lý do khác
Dưới đây là một số điều bổ sung để xem xét về việc thực hiện và triển khai của
bạn.
USN thay cho đặc tính
Do mỗi đối tượng tiếp tục tồn tại độc lập trong một kho lưu trữ đã có một Số thứ
tự cập nhật (USN) tăng đều, tại sao không sử dụng số đó thay vì một đặc tính tuỳ
chỉnh cho giá trị bộ đếm? Bạn có thể làm điều này nếu bạn đang định chấp nhận
một số thỏa hiệp, nhưng khác với việc tránh định nghĩa về bản thân đặc tính bộ
đếm, bạn sẽ không thực sự tiết kiệm được nhiều.
 Sự tiến triển bình thường của USN là được tăng lên một. Nếu bạn cần một
số mô hình tiến trình khác cho các số thứ tự của bạn, bạn sẽ không gặp may
đâu.
 Trên thực tế, mô hình phát triển CE cho USN chỉ được xác định một cách

mơ hồ. Việc sử dụng chính thức trên thực tế mà bạn có thể thực hiện với nó
là so sánh nó dựa vào giá trị bằng không hoặc so sánh hai USN với các giá
trị nhỏ hơn, lớn hơn hoặc bằng. Có khả năng là hành vi tăng-lên-một có thể
thay đổi trong một phiên bản CE tương lai, mặc dù nó vẫn sẽ là hành vi
tăng đều.
 Nói đúng ra, sự tăng lên của USN là không theo sự điều khiển của bạn.
Máy chủ CE tăng USN bất cứ khi nào đối tượng đã tồn tại được cập nhật,
chứ không chỉ khi một ai đó đã yêu cầu một số thứ tự mới.
 Bạn sẽ vẫn phải thực hiện số các chuyến đi khứ hồi của máy chủ giống
nhau để cập nhật đối tượng bộ phân phối hoặc tìm nạp giá trị USN. Không
có lợi thế về hiệu năng nào.
Nhiều bộ phân phối
Bất kể kỹ thuật mà bạn sử dụng cho mã thực hiện, việc cập nhật liên tục một đối
tượng duy nhất có thể gây ra một điểm nóng hiệu năng trong kho lưu trữ nếu khối
lượng cập nhật cao. Với cao, chúng ta muốn nói là cao theo các tiêu chuẩn cơ sở
dữ liệu. Vì vậy, ngay cả vài ngàn lần cập nhật mỗi ngày cũng không chắc là một
vấn đề. Với các khối lượng rất cao, bạn có thể muốn làm cho nhiều thứ có thể mở
rộng hơn bằng cách dùng nhiều đối tượng bộ phân phối với nhau mỗi bộ chịu
trách nhiệm về một số dải giá trị. Nói cách khác, các giá trị được phân phối bởi
các cá thể bộ phân phối khác nhau vẫn là duy nhất theo tổng thể.
Về API phiên bản Java 3.x
API phiên bản Java 3.x của CE không để lộ ra Số thứ tự cập nhật được sử dụng ở
trên. Trên thực tế, với hầu hết các hoạt động, mà API chuyển những thứ này lên
phần đầu của chúng và sử dụng một chính sách người viết-sau cùng-sẽ thắng. Điều
đó là có thể, nhưng quả khá là khó để viết một bộ phân phối vừa đúng chức năng
lại vừa đúng hiệu năng trong API phiên bản Java 3.x . Nếu các ràng buộc nghiệp
vụ của bạn cho phép nó, thì điều tốt nhất để bạn làm sẽ là di chuyển một phần
(hoặc tất cả) ứng dụng của bạn theo các API phiên bản 4.x của CE.

Suy nghĩ cuối cùng
Bài viết này đã trình bày nhiều kỹ thuật để triển khai thực hiện một bộ phân phối
số thứ tự. Giống như mọi thứ khác, có bao nhiêu vấn đề mà bạn muốn tiếp tục là
tùy thuộc một phần vào các yêu cầu nghiệp vụ và bất cứ điều gì khác mà bạn có
trong lịch trình thực hiện của mình. Nếu ai đó hỏi tôi triển khai thực hiện điều này
theo một cách cởi mở, hoàn toàn mạ vàng, thì nó sẽ giống như thế này:
 Sử dụng mã người viết-đầu tiên-thắng cuộc tương tự như trong Liệt kê 3.
 Đặt mã đó trong một servlet J2EE đơn giản. Bằng cách triển khai nó trong
một thùng chứa Web J2EE, chúng ta sẽ tự động có được việc điều chỉnh
quy mô, dự phòng lỗi, cách ly và các lợi ích khác của cơ sở hạ tầng J2EE.
 Hạn chế quyền truy cập viết P8 vào đối tượng hoặc các đối tượng bộ phân
phối sao cho những người dùng bình thường không thể bỏ qua servlet để
cập nhật giá trị đó.
 Cấu hình servlet với một vai trò RunAs có các quyền của Máy nội dung
(CE) để cập nhật các đối tượng bộ phân phối. (Xem thanh bên Sử dụng một
servlet J2EE).
 Nếu cần, hãy triển khai thực hiện một số lược đồ để xác minh rằng những
người yêu cầu có quyền đòi hỏi bộ phân phối cho một số. Điều này sẽ chỉ
thú vị nếu có một mối quan tâm về các số bị lãng phí.
 Hãy bắt đầu servlet với một giả định lạc quan rằng một chuyến đi khứ hồi
sẽ có chi phí thông thường để nhận được một số từ một bộ phân phối. Nói
cách khác, hãy bắt đầu với feelingUnlucky là sai. Hãy theo dõi xem bao lâu
thì điều đó chuyển thành sai trên thực tế. Khi nó sai nhiều hơn một tỷ lệ
phần trăm thời gian, hãy chuyển sang khung nhìn bi quan để luôn trả tiền
cho chi phí hai chuyến đi khứ hồi. Theo định kỳ hãy chuyển trở lại khung
nhìn lạc quan để xem mọi thứ đã thay đổi chưa.
 Khi cần thiết, hãy cung cấp mã tiện ích phía máy khách để thực hiện các
cuộc gọi đến servlet để nhận được các số thứ tự.
Không cần phải nói, tôi cũng sẽ yêu cầu thanh toán về các bánh nướng nhỏ này.
Ngon tuyệt!

Mục lục

 Mở đầu
 Đồng bộ Java hay .NET
 Đối tượng bộ phân phối P8
 Các khóa hợp tác của Máy nội dung (CE) FileNet
 Gắn với trình xử lý sự kiện
 Người viết đầu tiên sẽ thắng
 Các lý do khác
 Suy nghĩ cuối cùng