The question  you have asked, falls into a very interesting area of
enterprise applications: Concurrency Management.

There are various good  resources you can study to get the idea like Martin
Fowler's master-peace at: http://martinfowler.com/eaaCatalog/ and Sun's
J2EE/EJB patterns catalog.

If you want a quick answer, I would say that both locking strategies you
have asked are feasible. They are know as 'Optimistic' and 'Pessimistic'
locking strategies.

Each enterprise, based on its requirement and scenario, generally uses one
of these two locking systems (Although there are other strategies too).

If the opportunity to fall into a transaction rollback is high - based on
your system  flow - then pessimistic lock  is better. Other wise try to use
optimistic lock (let every thing happen, unless sth. bad happens - UNIX
like way of thinking:) every where possible (for your system, sth. like
option 3 then).

the quick answer is no and while item  T is in user  A's basket it is reserved already,

isolation within J2EE guarantees that the same data is immune from concurrent access of multiple users, so that users' access are isolated from one another but this is under your own control and you can define the correct isolation level to align with your system  efficiency, scalability and reliability

your problem looks like a dirty read happening while user B might access item T when user A has not committed its operation on item T yet. here you need to choose  a proper isolation level to make sure user B reads the committed data only. you might need to use locking on the shared data here or perform serialization of transactions for users. this might be a bit tricky as when you have parallel transactions, the improper isolation level will lead to disaster.

from usability point of view (which I guess is your main point for this question) IMHO, you might need to lock  the data (as you transactions are parallel) and user B might can be provided to reserve the purchase for item T and can be asked to come back later this is because your system still does not have a committed operation on item T.
so in simple terms, when user B wants to purchase T, and T is in basket of user A, system can tell B to check again later or reserve and purchase or get notified of availability  later, but definitely you should not allow both of them to purchase the single available item T.

let them both put it in their basket, and show number of available items,
just let the one who checks in faster buy the stuff and tell the next one the item  is not available.

this is not right, you should always consider the real world scenario when making such decisions .

if you imagine you and another guy are in a shop and there is only one pack of chips left, and you are the first person to take that pack, the other person has the choice of i) waiting to see if you are going to buy that or
ii) he can come back later and check the availability  of that pack again,

but it is "physically" impossible for both of you to put that same pack in both baskets.

the reason I am emphasising on the word "physically" is that all the templates, patterns and scenarios that we are using in software industry are coming from real world examples, this question  is a functional requirement type question, but even design patterns that we use within our designs, are initiated from construction industry,so you should always consider real-world examples ,

yes you are right sasan
I agree with real world senarios
but real world senario of e-shop is more like order by phone shops.
in order by phone you may order some thing and when they bring your staff they may tell you
we are sorry we run out of X and they may also tell you that they have bringed you Y instead!
I mean they usually don't let customer go! :D
or better say they use optimistic locking and they use "excuse me" or "replacement strategy" to handle exceptions! ;-)

but the operator should also be careful of not making the customer confused.

they can simply tell you that the item  is reserved by someone else, you may come back later or we will let you know shortly if it becomes available, but they can't let you have it and then take it away from your hand, :)

it is the same as buying a house, you might give  an offer on a house and claim to buy it, so others can only wait and see if you are definitely going to buy it, if not, they will start to bid, but what is guaranteed is that, the agent that wants to sell the house , as you said, surely doesn't want to loose either of the customers.

keeping it simple, will make it easier for both operator and customer to deal with it easier, that's how I look at it anyway, but I guess it is up to the implementation to make the nice and neat for the customer to encourage them to come back, by having services such as notification of availability  of the items,

yes you are right I think a lot about this, and after one day of thinking I reached to this conclusion that it should depend on business.
for example the correct solution for buying house will not work on grocery store.

no necessarily; there is one thing in common, and that is the reliability of service,
the seller can not promise you something that can not fulfill. even in grocery store if someone wants to buy the last pack of apples, what are you going to do? either watch the guy or come back tomorrow,

looking at e-shopping examples, such as amazon, if there is no item  i.e. book available, they won't promise you one, all they do is asking you if you want to register for the item and they will let you know as soon as it becomes available.

at the end of the day, its just the system  engineers' decision as how they want their system to function, unless you can think of another solution,

the prerequisite for this use-case was that the system can not offer more than one of the available item, so in case two actors are using this purchase use-case, how your system is going to respond for this alternate?

I think about your scenario,

Solution one :
Let both of them to add item  
in their baskets and at the end of their sessions
that decide to confirm their shopping, if item catch by some one give  Correct Sign to another.

Solution two :
Don't let both of them to add  item to their baskets and keep your item
Sync, that it means  you should risk about some item in some times Lock or disable to choose  about it And attention to this advice that you should keep item Sync because until item quit (Give Up) from some one, item shows UnLock.

But if you could keep Sync your Object in all sessions of customers, it (Solution two) is better, because your customers don't wanna waste their time  and return to choose another or find out it is like a joke to choose their favorite Item.

you are right, if I ever let user  B to buy T, A will definately loose his trust into the program and surely will not come back again. so I will need to provide something like a wishlist to add  T for later availability  and inform B of that.
anyway, thatnk you all.