Tôi có câu hỏi liên quan đến vấn đề hiệu suất có thể khi sử dụng chú thích @EJB. Hãy tưởng tượng kịch bản sau đây@EJB tiêm vs tra cứu - vấn đề hiệu suất
public class MyBean1 implements MyBean1Remote{
@EJB
private MyBean2Remote myBean2;
@EJB
private MyBean2Remote myBean3;
...
@EJB
private MyBean20Remote myBean20;
}
Có một hạt có nhiều phụ thuộc vào các hạt khác. Theo đặc tả EJB nếu tôi muốn tiêm MyBean1Remote cho một số bean khác, thùng chứa sẽ phải lấy tất cả các phụ thuộc bắt buộc từ nhóm của nó tiêm nó vào MyBean1Remote và sau đó tiêm tham chiếu đến MyBean1Remote stub.
như vậy trong sau nhu cầu kịch bản chứa để dự trữ 20 EJB (myBean1 và 19 phụ thuộc của nó)
public class MyAnotherBean implement MyAnotherRemote{
@EJB
private MyBean1Remote myBean1
}
Hãy nói rằng trong nhiều trường hợp, chúng tôi sẽ chỉ sử dụng phụ thuộc duy nhất cho mỗi phương thức kinh doanh của myBean1. Kết quả là mỗi lần chúng ta muốn tiêm đậu đó, chúng ta buộc container chứa nhiều EJB không cần thiết. Cho phép giả định rằng chúng ta đang hoạt động trên các bean từ xa, vì vậy có lẽ container cũng sẽ cần thực hiện một số thuật toán cân bằng tải trước khi tiêm các bean phụ thuộc.
Câu hỏi:
Sẽ không có dự phòng tài nguyên không cần thiết nguyên nhân và nhiều hơn nữa về vấn đề hiệu suất trong khi hoạt động trong môi trường cluster?
Có thể ServiceLocator cũ tốt hơn có thể là giải pháp tốt hơn vì với cách tiếp cận này, chúng tôi sẽ yêu cầu EJB cụ thể khi chúng tôi thực sự cần nó?
+1 Vâng, đây cũng là câu trả lời hay :) Bản thân cá thể không bao giờ được tiêm, nhưng proxy là. Bên cạnh đó, như trong câu trả lời của tôi, các trường hợp thực tế trong hồ bơi đã có tất cả các phụ thuộc của họ được giải quyết. –