Nghiên cứu cơ sở dữ liệu CoakroachDB và xử lí bằng java | Bài tập lớn kết thúc học phần Lập trình hướng đối tượng | Trường Đại học Phenikaa

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC PHENIKAA
BÀI TẬP LỚN KẾT THÚC HỌC PHẦN Lập trình hướng đối tượng
Đề bài: Nghiên cứu cơ sở dữ liệu CoakroachDB và xử lí bằng java
Lớp: Lập trình hướng đối tượng_1.2(14IT).2_LT Thành viên nhóm 8:
Lại Tiến Đức MSV: 20010851
Đỗ Minh Quân MSV: 20010879
Trần Tâm Long MSV: 20010875
Nguyễn Hoàng Anh MSV: 20010840
Giảng viên: Trần Đăng Hoan = HÀ NỘI, 06/2022 Mục Lục
Lời mở đầu ........................................................................ 3
CoakroachDB là gì ? ......................................................... 3
Khi nào thì CockroachDB là lựa chọn tốt? ....................... 3
Mục tiêu của CockroachDB .............................................. 3
Đề tài nghiên cứu: Serializable, Lockless, Distributed: ... 4
Isolation in CockroachDB ................................................. 4
Cung cấp thực thi có thể nối tiếp hóa: ............................ 7
Đồ thị khả năng tuần tự hóa: ........................................... 7
Xung đột Write-Read Cơ sở dữ liệu MVCC ................. 10
Xung đột Read-Write Đọc bộ nhớ cache dấu thời
gian .............................................................................. 12
Xung đột Write-Write chỉ có thể ghi phiên bản mới
nhất của khóa .............................................................. 13
Có thể phục hồi với lập lịch trình nghiêm ngặt ............ 13
Thực thi lập lịch trình nghiêm ngặt............................... 15
Cách cài đặt CockRoachDB trên window ....................... 18
Xây dựng ứng dụng Java với CockroachDB Xử lí Giao 18
dịch .................................................................................. 18
Kết luận ........................................................................... 29 Lời mở đầu CoakroachDB là gì ?
CockroachDB là một cơ sở dữ liệu SQL phân tán được xây dựng trên
một kho khóa-giá trị giao dịch và nhất quán mạnh mẽ. Nó có quy mô
theo chiều ngang; sống sót sau các lỗi đĩa, máy, giá đỡ và thậm chí cả
trung tâm dữ liệu với sự gián đoạn độ trễ tối thiểu và không có sự can
thiệp thủ công; hỗ trợ các giao dịch ACID nhất quán mạnh mẽ ; và
cung cấp một API SQL quen thuộc để cấu trúc, thao tác và truy vấn dữ liệu.
Khi nào thì CockroachDB là lựa chọn tốt?
CockroachDB rất phù hợp cho các ứng dụng yêu cầu dữ liệu đáng tin
cậy, sẵn có và chính xác cũng như thời gian phản hồi mili giây, bất kể
quy mô. Nó được xây dựng để tự động sao chép, cân bằng lại và phục
hồi với cấu hình và chi phí hoạt động tối thiểu. Các trường hợp sử dụng cụ thể bao gồm:
• OLTP được phân phối hoặc sao chép
• Triển khai nhiều trung tâm dữ liệu • Triển khai đa vùng
• Di chuyển trên đám mây
• Các sáng kiến cơ sở hạ tầng được xây dựng cho đám mây Mục tiêu của CockroachDB
CockroachDB được thiết kế để đáp ứng các mục tiêu sau:
Làm cho cuộc sống của con người dễ dàng hơn. Điều này có nghĩa là ít
chạm và tự động hóa cao cho người vận hành và đơn giản để giải thích cho các nhà phát triển.
• Cung cấp tính nhất quán hàng đầu trong ngành, ngay cả khi triển
khai quy mô lớn. Điều này có nghĩa là cho phép các giao dịch phân
tán, cũng như loại bỏ nỗi đau của các vấn đề về tính nhất quán cuối
cùng và các lần đọc cũ.
• Tạo cơ sở dữ liệu luôn bật chấp nhận đọc và ghi trên tất cả các nút
mà không tạo ra xung đột.
• Cho phép triển khai linh hoạt trong mọi môi trường, không ràng
buộc bạn với bất kỳ nền tảng hoặc nhà cung cấp nào.
• Hỗ trợ các công cụ quen thuộc để làm việc với dữ liệu quan hệ (tức là SQL).
Đề tài nghiên cứu: Serializable, Lockless,
Distributed: Isolation in CockroachDB -
CockroachDB hỗ trợ gói nhiều câu lệnh SQL vào một giao dịch tất
cả hoặc không có gì. Mỗi giao dịch đảm bảo ngữ nghĩa ACID trải dài
các bảng và hàng tùy ý, ngay cả khi dữ liệu được phân phối. Nếu một
giao dịch thành công, tất cả các đột biến sẽ được áp dụng cùng với đồng
thời ảo. Nếu bất kỳ phần nào của giao dịch không thành công, toàn bộ
giao dịch sẽ bị hủy bỏ và cơ sở dữ liệu được giữ nguyên. CockroachDB
đảm bảo rằng trong khi một giao dịch đang chờ xử lý, nó được cách ly
khỏi các giao dịch đồng thời khác với sự cách ly có thể tuần tự hóa . -
Để có một cuộc thảo luận chi tiết về ngữ nghĩa giao dịch của
CockroachDB, hãy xem cách CockroachDB thực hiện các giao dịch
nguyên tử phân tán và Serializable, Lockless, Distributed: Isolation trong CockroachDB . -
Vài tháng trước, đã có thảo luận về cách các giao dịch phân tán
của CockroachDB được thực thi nguyên tử. Tuy nhiên, cuộc thảo luận
đó không đầy đủ; nó đã bỏ qua khái niệm đồng thời, trong đó nhiều giao
dịch đang hoạt động trên cùng một tập dữ liệu cùng một lúc.
CockroachDB, giống như tất cả các hệ thống cơ sở dữ liệu, cố gắng cho
phép nhiều đồng thời nhất có thể để tối đa hóa quyền truy cập vào tập dữ liệu. -
Thật không may, đảm bảo tính nguyên tử không đủ để giữ cho cơ
sở dữliệu nhất quán trong thế giới các giao dịch đồng thời. Nhắc lại đảm bảo đó:
Đối với một nhóm các thao tác cơ sở dữ liệu, tất cả các thao tác đều
được áp dụng hoặc không có thao tác nào được áp dụng. -
Điều này không giải quyết là cách mà các giao dịch đồng thời có
thể xen kẽ nhau. Các thao tác riêng lẻ (đọc và ghi) trong một giao dịch
không xảy ra đồng thời; có thời gian giữa các hoạt động riêng lẻ. Trong
một hệ thống đồng thời, một giao dịch có thể cam kết trong thời gian
thực hiện của giao dịch thứ hai; ngay cả khi giao dịch đầu tiên (T1) cam
kết nguyên tử, điều này vẫn có thể cho phép các hoạt động sau đó trong
giao dịch thứ hai (T2) xem kết quả của T1, ngay cả khi các hoạt động
trước đó trên T2 không thấy kết quả của T1. Việc xen kẽ này có thể tạo
ra một số điểm bất thường không mong muốn , cuối cùng phá vỡ tính
nhất quán của cơ sở dữ liệu. -
Để bảo vệ khỏi những dị thường này, chúng tôi yêu cầu đảm bảo Cách ly :
Đối với một nhóm các giao dịch nguyên tử, đồng thời, cam kết của một
giao dịch không được xen kẽ với các hoạt động của giao dịch khác. -
Sự cô lập hoàn hảo có thể đạt được một cách đáng kể thông qua
thực hiện nối tiếp: thực hiện tất cả các giao dịch trên hệ thống tại một
thời điểm, không có đồng thời. Điều này có ý nghĩa về hiệu suất khủng
khiếp; may mắn thay, nó cũng không cần thiết để đạt được sự cô lập
hoàn hảo. Nhiều cơ sở dữ liệu đồng thời, bao gồm cả CockroachDB,
thay vào đó cung cấp khả năng thực thi có thể tuần tự hóa , tương đương
với thực thi nối tiếp trong khi cho phép mức độ giao dịch đồng thời đáng kể. -
Mức độ cách ly mặc định của CockroachDB được gọi là Ảnh chụp
có thể hóa nối tiếp. Đó là một hệ thống điều khiển đồng thời lạc quan,
nhiều phiên bản, được sắp xếp theo dấu thời gian với các thuộc tính sau:
+ Serializable: Trạng thái cơ sở dữ liệu kết quả tương đương với việc
thực hiện nối tiếp các giao dịch thành phần.
+ Recoverable: Một tập hợp các giao dịch cơ sở dữ liệu được coi là có
thể khôi phục được nếu các giao dịch bị hủy bỏ hoặc bị hủy bỏ sẽ không
ảnh hưởng đến trạng thái cơ sở dữ liệu. Hệ thống cam kết nguyên tử của
chúng tôi đã đảm bảo rằng các giao dịch riêng lẻ có thể khôi phục được;
hệ thống Cô lập của chúng tôi sử dụng lập lịch nghiêm ngặt để đảm bảo
rằng bất kỳ sự kết hợp giao dịch nào cũng có thể khôi phục được.
+ Lockless: Các hoạt động thực thi mà không cần khóa tài nguyên. Tính
đúng đắn được thực thi bằng cách hủy bỏ các giao dịch vi phạm khả
năng tuần tự hóa hoặc lập lịch nghiêm ngặt.
+ Distributed: Không có nhà tiên tri trung tâm, điều phối viên hoặc dịch
vụ liên quan đến hệ thống này.
Cung cấp thực thi có thể nối tiếp hóa:
- CockroachDB sử dụng thứ tự dấu thời gian nhiều phiên bản để đảm
bảo rằng lịch sử cam kết giao dịch hoàn chỉnh của nó có thể được tuần
tự hóa. Kỹ thuật cơ bản đã là tài liệu sách giáo khoa trong ba thập kỷ,
nhưng chúng ta sẽ xem qua cách thức hoạt động của nó:
Đồ thị khả năng tuần tự hóa:
Để chứng minh tính đúng đắn của thứ tự dấu thời gian, xem xét lý thuyết
khả năng tuần tự hóa, và cụ thể là một trong những khái niệm cốt lõi của
nó, biểu đồ khả năng tuần tự hóa. Biểu đồ này được sử dụng để phân
tích lịch sử của các giao dịch cơ sở dữ liệu về các xung đột hoạt động .
Về lý thuyết, xung đột xảy ra khi hai giao dịch khác nhau thực hiện một
thao tác trên cùng một phần dữ liệu (lần lượt), trong đó ít nhất một trong
các thao tác là ghi. Hoạt động thứ hai được cho là xung đột với hoạt
động đầu tiên. Có ba loại xung đột:
• Read-Write (RW) - Thao tác thứ hai ghi đè lên một giá trị đã
được đọc bởi thao tác đầu tiên.
• Write-Read (WR) - Thao tác thứ hai đọc một giá trị được ghi bởi thao tác đầu tiên.
• Write-Write (WW) - Thao tác thứ hai ghi đè lên một giá trị đã
được ghi bởi thao tác đầu tiên.
Đối với bất kỳ lịch sử giao dịch nhất định nào, những xung đột này có
thể được sử dụng để tạo biểu đồ tuần tự hóa, là biểu đồ có hướng liên kết tất cả các giao dịch.
• Các giao dịch là các nút trong biểu đồ.
• Bất cứ khi nào một hoạt động xung đột với một hoạt động từ một
giao dịch khác, hãy vẽ một cạnh trực tiếp từ hoạt động xung đột
sang hoạt động bị xung đột.
Ví dụ về biểu đồ khả năng tuần tự hóa cho lịch sử giao dịch đơn giản.
Và bây giờ chúng ta đi đến một tuyên bố quan trọng của lý thuyết này:
một lịch sử được đảm bảo là có thể tuần tự hóa nếu (và chỉ khi) đồ thị
tuần tự hóa của nó là dòng xoay chiều.
Ví dụ về lịch sử giao dịch với biểu đồ tuần tự hóa theo chu kỳ. Lịch sử này không thể tuần tự hóa.
Thứ tự dấu thời gian của CockroachDB đảm bảo một biểu đồ khả
năng tuần tự hóa xoay chiều và điều này dễ dàng chứng minh:
• Mỗi giao dịch được gán một dấu thời gian (từ nút mà nó bắt đầu)
khi nó bắt đầu. Tất cả các hoạt động trong giao dịch đó diễn ra tại
cùng một dấu thời gian này, trong suốt thời gian của giao dịch.
• Các hoạt động riêng lẻ có thể xác định cục bộ khi nào chúng xung
đột với một hoạt động khác và dấu thời gian giao dịch của hoạt
động bị xung đột là gì.
• Các hoạt động chỉ được phép xung đột với các dấu thời gian trước
đó; một giao dịch không được phép cam kết nếu làm như vậy sẽ
tạo ra xung đột với dấu thời gian sau này.
Bằng cách không cho phép bất kỳ xung đột nào đi ngược lại hướng theo
thứ tự dấu thời gian, đồ thị khả năng tuần tự hóa theo chu kỳ là không
thể. Tuy nhiên, chúng ta hãy khám phá chi tiết cách CockroachDB thực
sự phát hiện và không cho phép những xung đột này.
+ Xung đột Write-Read Cơ sở dữ liệu MVCC:
Đây là lúc khía cạnh “đa phiên bản” trong cơ chế điều khiển của chúng
tôi phát huy tác dụng. Các khóa CockroachDB không lưu trữ một giá trị
duy nhất, mà lưu trữ nhiều phiên bản có dấu thời gian của giá trị đó. Các
lần ghi mới không ghi đè lên các giá trị cũ, mà tạo ra một phiên bản mới
với dấu thời gian mới hơn.
So sánh kho giá trị nhiều phiên bản với một kho giá trị đơn
Thao tác đọc trên một khóa trả về phiên bản mới nhất có dấu thời gian thấp hơn thao tác:
Do đó, trong CockroachDB không thể hình thành xung đột WR với các
giao dịch sau này; các thao tác đọc sẽ không bao giờ đọc một giá trị có dấu thời gian sau này.
+ Xung đột Read-Write Đọc bộ nhớ cache dấu thời gian:
Trên bất kỳ thao tác đọc nào, dấu thời gian của thao tác đọc đó được ghi
lại trong bộ đệm dấu thời gian nút-cục bộ . Bộ nhớ đệm này sẽ trả về dấu
thời gian gần đây nhất mà khóa đã được đọc.
Tất cả các hoạt động ghi đều tham khảo bộ đệm dấu thời gian cho khóa
mà chúng đang ghi; nếu dấu thời gian trả về lớn hơn dấu thời gian hoạt
động, điều này cho thấy xung đột RW với dấu thời gian sau đó. Để
không cho phép điều này, hoạt động (và giao dịch của nó) phải được hủy
bỏ và bắt đầu lại với dấu thời gian sau đó.
Bộ đệm dấu thời gian là bộ đệm theo khoảng thời gian, có nghĩa là các
khóa của nó thực sự là các dải khóa. Nếu một hoạt động đọc thực sự là
một vị từ hoạt động trên một loạt các khóa (chẳng hạn như quét), thì
toàn bộ phạm vi khóa được quét sẽ được ghi vào bộ đệm dấu thời gian.
Điều này ngăn chặn xung đột RW trong đó khóa đang được ghi không
xuất hiện trong quá trình quét.
Bộ nhớ cache dấu thời gian là cấu trúc dữ liệu LRU trong bộ nhớ (ít
được sử dụng gần đây nhất) có giới hạn về kích thước, với các dấu thời
gian cũ nhất sẽ bị loại bỏ khi đạt đến giới hạn kích thước. Để xử lý các
khóa không có trong bộ nhớ cache, chúng tôi cũng duy trì một "dấu
nước thấp", tương đương với dấu thời gian được đọc sớm nhất của bất
kỳ khóa nào có trong bộ nhớ cache. Nếu một thao tác ghi ghi vào một
khóa không có trong bộ đệm, thì thay vào đó, "dấu nước thấp" sẽ được trả về.
+ Xung đột Write-Write chỉ có thể ghi phiên bản mới nhất của khóa:
Nếu một thao tác ghi cố gắng ghi vào một khóa, nhưng khóa đó đã có
phiên bản có dấu thời gian muộn hơn chính thao tác đó, thì việc cho
phép thao tác sẽ tạo ra xung đột WW với giao dịch sau đó. Để đảm bảo
khả năng tuần tự hóa, hoạt động (và giao dịch của nó) phải được hủy bỏ
và khởi động lại với dấu thời gian sau đó.
Bằng cách chọn thứ tự dựa trên dấu thời gian và từ chối tất cả các xung
đột không đồng ý với thứ tự đó, Ảnh chụp nhanh có thể hóa nối tiếp của
CockroachDB đảm bảo một lịch trình có thể thay đổi theo thứ tự.
Có thể phục hồi với lập lịch trình nghiêm ngặt:
- Trong khi các quy tắc xung đột trước đây đủ để đảm bảo lịch sử có thể
tuần tự hóa, một mối quan tâm khác nảy sinh khi hai giao dịch chưa
cam kết có xung đột: ngay cả khi xung đột đó được các quy tắc sắp xếp
dấu thời gian của chúng tôi cho phép, các quy tắc bổ sung vẫn được
yêu cầu để đảm bảo rằng lịch giao dịch vẫn có thể khôi phục được .
- Vấn đề có thể được giải thích bằng một ví dụ:
Xem xét hai giao dịch [T1, T2], trong đó timestamp (T1) (T2). T1 ghi vào một phím 'A'. Sau đó, T2 đọc từ phím 'A', trước khi T1 thực hiện.
Xung đột này được cho phép theo quy tắc đặt hàng dấu thời gian của
chúng tôi. Tuy nhiên, giá trị nào của đọc T2 nên truy xuất từ 'A'?
• Giả sử nó bỏ qua giá trị không được cam kết được viết bởi T1 và
thay vào đó lấy giá trị trước đó. Nếu cả T1 và T2 đều cam kết, điều
này sẽ tạo ra xung đột WR với T2 (T1 sẽ ghi đè một giá trị được
đọc bởi T2). Điều này vi phạm đảm bảo đặt hàng dấu thời gian của
chúng tôi và do đó khả năng tuần tự hóa.
• Giả sử nó truy xuất giá trị được ghi bởi T1. Nếu T2 cam kết, nhưng
T1 sau đó hủy bỏ, điều này sẽ vi phạm tính nguyên tử của T1: T1
vẫn sẽ có ảnh hưởng đến trạng thái cơ sở dữ liệu, ngay cả khi nó bị hủy bỏ.
- Do đó, không thể có khả năng nào xảy ra: trong tình huống này, không
có cách nào mà T2 có thể được cam kết một cách an toàn trước T1
trong khi vẫn duy trì một lịch trình có thể phục hồi được.
- CockroachDB sử dụng lập lịch nghiêm ngặt để xử lý tình huống này:
các hoạt động chỉ được phép đọc hoặc ghi đè các giá trị đã cam kết ;
các phép toán không bao giờ được phép thực hiện trên một giá trị không được cam kết.
Thực thi lập lịch trình nghiêm ngặt:
Trong kho dữ liệu MVCC, ý định về một khóa (nếu có) được lưu trữ
trong một giá trị đặc biệt, sắp xếp ngay trước giá trị được cam kết gần đây nhất:
Các hành động lập lịch nghiêm ngặt được yêu cầu trong hai trường hợp:
nếu một thao tác đọc gặp phải một ý định có dấu thời gian thấp hơn hoặc
nếu một hành động ghi gặp bất kỳ ý định nào từ một giao dịch khác (bất
kể thứ tự dấu thời gian). Trong những tình huống này, có hai tùy chọn có sẵn cho CockroachDB:
• Nếu giao dịch thứ hai có dấu thời gian cao hơn, nó có thể đợi giao
dịch đầu tiên cam kết hoặc hủy bỏ trước khi hoàn tất thao tác.
• Một trong hai giao dịch có thể bị hủy bỏ.
Là một hệ thống lạc quan (không chờ đợi), CockroachDB luôn chọn hủy
bỏ một trong các giao dịch. Quy trình xác định giao dịch như sau:
• Giao dịch thứ hai (đang gặp một ý định) tra cứu bản ghi giao dịch
của giao dịch đầu tiên, vị trí của nó hiện diện trong ý định.
• Giao dịch thực hiện một “ cú hích ” trên bản ghi giao dịch được
phát hiện. Hoạt động đẩy như sau:
o Nếu giao dịch đầu tiên đã được cam kết (ý định chưa được
làm sạch), thì giao dịch thứ hai có thể xóa ý định và tiến hành
như thể ý định là một giá trị bình thường.
o Tương tự như vậy, nếu giao dịch khác đã bị hủy bỏ, ý định có
thể bị xóa và giao dịch thứ hai có thể tiếp tục như thể ý định không có.
o Nếu không, giao dịch còn tồn tại được xác định theo mức độ ưu tiên .
Sẽ không phải là tối ưu nếu luôn luôn hủy bỏ người đẩy
hoặc người đẩy; có những trường hợp cả hai giao dịch
sẽ cố gắng thúc đẩy giao dịch kia, vì vậy “chiến thắng”
phải mang tính xác định giữa bất kỳ cặp giao dịch nào.
Do đó, mỗi bản ghi giao dịch được chỉ định một mức
độ ưu tiên ; ưu tiên là một số nguyên. Trong hoạt động
đẩy, giao dịch có mức độ ưu tiên thấp nhất luôn bị hủy
bỏ (nếu mức độ ưu tiên bằng nhau, giao dịch có dấu
thời gian cao hơn sẽ bị hủy bỏ. Trong trường hợp cực
kỳ hiếm khi cả hai đều bằng nhau, giao dịch đẩy sẽ bị hủy bỏ).
Các giao dịch mới có mức độ ưu tiên ngẫu nhiên. Nếu
một giao dịch bị hủy bỏ bởi một hoạt động đẩy và được
khởi động lại, thì mức độ ưu tiên mới của nó là
max(randomInt(), [priority of transaction that caused
the restart] - 1]);điều này có tác dụng xác suất tăng mức
độ ưu tiên của một giao dịch nếu nó được khởi động lại nhiều lần.
Bằng cách này, tất cả các xung đột giữa các giao dịch không được cam
kết sẽ được giải quyết ngay lập tức bằng cách hủy bỏ một trong các giao
dịch, do đó thực thi lập lịch nghiêm ngặt và đảm bảo rằng tất cả lịch sử
giao dịch đều có thể khôi phục được.
Lưu ý về các giao dịch bị bỏ qua:
Như đã đề cập trước đó, trong một môi trường đồng thời, chúng ta
không còn có thể cho rằng các ý định ghi chưa được giải quyết thuộc về
các giao dịch bị bỏ rơi; chúng ta phải giải quyết các giao dịch bị bỏ rơi
theo một cách khác. Hệ thống ưu tiên đã hủy bỏ các giao dịch bị bỏ rơi
một cách xác suất - các giao dịch bị chặn bởi giao dịch bị bỏ rơi cuối
cùng sẽ có mức độ ưu tiên đủ cao để chiếm đoạt nó.
Tuy nhiên, cũng thêm dấu thời gian nhịp tim vào mọi giao dịch. Trong
khi đang diễn ra, một giao dịch đang hoạt động có trách nhiệm cập nhật
định kỳ dấu thời gian nhịp tim trên bản ghi giao dịch trung tâm của nó;
nếu một hoạt động đẩy gặp một giao dịch có dấu thời gian nhịp tim đã
hết hạn, thì giao dịch đó được coi là bị bỏ qua và có thể bị hủy bỏ bất kể mức độ ưu tiên.
Cách cài đặt CockRoachDB trên window
https://www.cockroachlabs.com/docs/v22.1/install- cockroachdbwindows.html
Xây dựng ứng dụng Java với CockroachDB Xử lí Giao dịch
Tự động xử lý các lần thử lại giao dịch bằng cách gói các giao dịch
trong một hàm thứ tự cao hơn. Nó cũng bao gồm một phương thức
để kiểm tra logic xử lý thử lại.
public class Sample implements Serializable {
private static final Random RAND = new Random();
private static final boolean FORCE_RETRY = false;
private static final String RETRY_SQL_STATE = "40001";
private static final int MAX_ATTEMPT_COUNT = 6; //
Tương ứng với bảng cơ sở dữ liệu "tài khoản". public static class Account { public long id; public long getId() { return id; } public BigDecimal balance;
public BigDecimal getBalance() { return balance; }
public void setBalance(BigDecimal newBalance) { this.balance = newBalance; }
// Hàm tạo tiện lợi. public Account(int id, int balance) { this.id = id;
this.balance = BigDecimal.valueOf(balance); }
// Hibernate cần một phương thức khởi tạo public Account() { } }
private static Function addAccounts() throws JDBCException { Function f = s ->
{ BigDecimal rv = new BigDecimal(0); try {
s.save(new Account(1, 1000)); s.save(new Account(2, 250));
s.save(new Account(3, 314159)); rv = BigDecimal.valueOf(1);
System.out.printf("APP: addAccounts() --> %.2f\n", rv); } catch (JDBCException e) { throw e; } return rv; }; return f; }