I don't have a great amount of experience with Entity Beans and would like to ask a question to those who've been around the block a few times with this one.
The application is for movie theatre ticket sales. I think I'll have a construct called a 'Showing' that will represent a theatre, so it will model a large room with a number of seats at a point in time. (Note: the same room, same seats, will be allocated for different seat holders in just a few hours!)
My question: Do you think it would be good practice to represent the Showing as a composite entity bean? The Showing class would have attributes like startTime, movie, roomNumber, etc. and would aggregate a class called 'Seats' that holds information about the number of seats for the particular room, and which have been reserved or not. (Note: A theatre may have more than one room, and each room may have different Seats, i.e. different number of seats, premium tickets, etc. So 'Seats' will change for different Showings and must be up-to-date in regard to how many tickets have been sold and how many can yet be sold.)
Please note that whatever mechanism is used to represent this collection of seats, it will have to support viewing and updating by many concurrent users. There will be a web front end for ticket sales!
My question-- do you think there's a better way to represent the matrix of sold-vs-unsold seats than the above arrangement, implemented with a composite Entity Bean?
Any ideas or suggestions will be greatly appreciated!