you'd most likely want to use optimistic locking in this case
OK, but a user could get fairly hacked off if we let him into an order with loads of complex stuff on the screen, he then takes 5 minutes to enter stuff, and then we find that conflicting updates have occurred.
I really need pessimistic locking (which I know introduces other issues), but that depends on a transaction(?). If I need to do my own thing, fair enough, but if there's a way of achieving it within the spec, I'd obviously prefer to do that.
Actually, when you think it through, pessimistic locking isn't the answer.
If someone just wanders off half-way through the transaction (for lunch or whatever), or their plug gets pulled from the wall, then pessimistic locking is going to cause all sorts of problems.
It's more a question of designing the application so that two users will not naturally be updating the same entity at the same time, and then using optimistic locking.
I agree ;-)