The first point is a very good one, I wouldn't have thought of it!
The second point is certainly arguable. I see where your coming from, but if it's a business rule, it by definition belongs in the model layer.
Remember, view is easy, the controller interfaces the two, and business logic of an application is the model layer.
If you define the controller as the portion that *merely* interfaces the view with the actual working objects (ie a Command servlet), then yes. What I was trying to get at is that a DAO should be responsible for exactly that -- accessing the data. It is, IMO, ill conceived to use the DAO to determine whether a row is locked and therefore whether an item is available.
That aside, I really do like your idea about kind of putting "a hold" on the class. I think that's a very good suggestion and a good model to follow.
but in the end Justin, you would do well, I think, to do this in the database, i.e., have a "locked" field as write to it. The complication there is you'll need some method to unlock "abandoned" items periodically.
I suppose my objection to handling in the database is not so much with the locks, but more with the combination of browsing behavior and inventory in a single table. Storing information about a user's cart in the database has its advantages -- namely sharing amongst machines in a cluster and persistence across restarts -- but anytime you have multiple hands (from multiple logical processes) in the cookie jar, I get nervous about maintaining integrity.
Ultimately, I like Eric Earle's dual-table suggestion as it accomplishes both accurate, fail-fast inventory reporting for buyers, and separation of the browsing and buying data... along with the persistence and locking benefits of doing it in the DB.
Good luck on your impl, Mufaddal... justin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
