If you are running a 1ghz machine with a gig of ram... unless you write some really really REALLY ugly code I cannot imagine you having a performance hit with 10 simultaneous users.
Some thoughts on architecture. If this is your first real Java web appand you are doing it to learn, do NOT use the various frameworks like STruts, Velocity, or Tapestry. Implement a minimal framework yourself. I highly suggest an action->controller->redirect based setup like Struts uses. Basically you send any page request that has to do any thinking to a servlet that looks at the request and forwards it to controller object based on the action specified in the URL, the controller gets the Request and Response objects and is responsible for handling it. Typically it will do processing, fill in relevent values on a Helper object which is then added to the request and forwarded to a JSP to make a pretty web page showing data pulled form the Helper. Sun's blue prints specify this as an example, and Struts uses it (ignore all the forms stuff in Struts until you get this concept down, but reading about it will help you there). Keep any application logic in the Controller or in objects it references (ideally in a domain model behind the controller if the app gets big, but for a small app these can be pushed together).
This will get you going for your ten simultaneous users. When you want to scale up, and if you dtermein you NEED a relational database... go use one. It is highly worth your time to write your own Object-Relational mapping system using a Persistence Gateway pattern (have a class for each object you need to persist that knows how to create, load, update, and delete that class) and use that class as a factory to get instances of your persistable classes. After you have done this look into O-R mappers like Hibernate, OJB (my favorite), Castor, or whatnot. When you make your O-R persistence layer you will probably want to investigate caching. Make sure to look at the Jakarta Commons COllections LRUMap class when you do this - it will save you much time and effort.
One thing you will run into while doing this is a cranky database because of lots of connections are being held. If you use POstgres it'll get cranky at about 33 conenctions unless you tweak its default settings (it defaults to a very low number of simultaneous connections) and you may want to investgate connection pooling. Writing a basically functional one isn't difficult, but grabbing the implementations from either JBoss or Jakarta Commons is easy too.
Don't worry about distributed objects (ie, EJB's or RMI) until you profile your system and see that it is efficient and is still dieing under the load. That is a different story, but remember Martin Fowler's first two rules of distributed objetcs: 1) Don't distribute your objects. 2) See rule number 1. It is usually cheaper and easier to buy a 4 cpu RISC server from HP than to pay a developer enough to make a distributed application - and if the 4 cpu machine doesn't handle the load, and the load is from you app, not the relational database then you are writing some cool stuff.