Hi everyone, I am designing a system for a school project, and actually this is my first J2EE project. I hope I can get some suggestions on EJB design. I am using WebLogic 6.1, so EJB version is 2.0. Oracle 9i for DB. One server that hosts everything, and browser client through web components. Project: Online help system. A customer can create a ticket that should contain all communication between customer support and the client. A ticket can contain multiple entries, and it can be closed by the customer, or support supervisor. The system creates knowledge base from all tickets, and customer support specify multiple keywords for the ticket. DB: [Customer]: (PK)CustomerID, and other customer info [Ticket]: (PK)TicketID, customerID, startDate, closedDate, category, subCategory, problemDesc, and other info. [TicketEntry]: (PK)TicketID and entryDate(compound key), content, and other problem-related info. [Employee]: (PK)EmployeeID, and other employee info. I am having trouble designing "TicketEJB" that represents the ticket. The ticket should contain all info in Ticket table, and all entries in TicketEntry that has the TicketID. At the beginning, I was thinking that there was TicketEntryEJB object too and TicketEJB should contain reference to them. However, each ticket can contain a lot of TicketEntries when the problem is persistant. I want a ticket to hold at least 50 entries. Does that force the system to hold a lot of EJBs in memory? If so, what's an alternative? If one TicketEJB loads 50 ticketEntryEJBs, that sounds like a lot of resources. TicketEJB can contain collections of non-EJB dependable objects. (In this case, ticket entry) But in that case, I have to code DB related functions and make TicketEntryDO persistent by hand? That sounds like a lot of work. Also, TicketEJB doesn't change much, while entries can be added frequently. If I want multiple support engineers and possibly multiple clients on one ticket, what is the best way to track changes in TicketEntryDO collection? Or is there a better solution? If you have any suggestion, please let me know. Thanks in advance.
I would definitely model TicketEntries as dependent objects of Ticket, and not as an EJB. It shouldn't be too complex to insert calls to queries when you want to add update or delete the TicketEntries. A little extra work will make performance much better.
How about using local interface for dependent entity EJBs ? Has anybody compared performance using local interface vs using dependent objects.
Joined: Dec 04, 2001
Hi David and Mukesh, Thank you for your reply. The one part I was having trouble understainding is how to manage transaction if I use Dependent object in stead of EJB. If I use TicketEntryEJB, I can use commit() and roleback() with some entries in dd, the container will manage the whole transaction process for me. Howerver, If I use dependent object, TicketEntryDO becomes my responsibility, and have to manage transaction by myself (Or do I?) If I do have to manage it, CMP becomes half bean-managed. So, subquestion is, "Is it meaningful to use CMP2.0 when EJB contains dependent objects?" I am still looking into documents. If anybody has an idea, or if you feel that I am misunderstanding something completely, please let me know. Thank you.