Hello,

I currently have an application that does not use Hibernate - and we are thinking of porting it to Hibernate for a couple reasons:
1. because it will give us more database independence
2. because it will solve a scalability issue we have with our current application.

While I *DO* believe that Hibernate can help us with our database independence issue, I do *NOT* believe it can solve our scalability issue - even though our application is really simple. I would love to be wrong on this.

Our server application is incredibly simple - it hands out tasks to clients. Each task has an id (primary key), a name, and an owner (foreign key to a client table). Everytime a client contacts the server it requests the "first available task" - where the first available task is defined as the task with the lowest primary key that has a null value in the owner column. The server application grabs this task, then updates that task to show that it is now owned by the calling client. The server application must make sure that no two clients are ever given the same task. Simple.

In order to implement this behavior, our current application LOCKS the task **TABLE**, finds the first available task (as defined above), updates that task to indicate the new owner based on the calling client, then commits the update - releasing the TABLE lock. This TABLE lock prevents another calling client from being given the same task. The system works very well - until we add a bazillion clients. At this point the TABLE locking we are doing is slowing the system down too much.

It seems to me that the model above has an inherent flaw in it that cannot be "overcome" by using Hibernate, Entity beans or any other technology. It seems that any technology placed "on top of" this model still is "database bound"...? In other words, the only solution that I can see to this particular problem, in the end, is serialization of access to the task table - hence the table lock.

Am I missing something obvious here? Can Hiberate really help with the performance with this model? Or do I just have to change the model itself? (I'm not sure what that model would look like). I need to manager customer expectations on this. They are all under the impression that if I just use Entity beans or Hibernate in a clustered environment, that we can just throw another server into the cluster if performance is lagging. I don't think so...

Any thoughts you might have would be greatly appreciated.

BTW: So far I'm finding my experimenting with Hibernate to be extremely fun.

-john

I would def rethink your model -- with or without hibernate. A few quick top-of-the-head thoughts:

If you really want to do a DB locking pattern, row lock instead of table lock. For instance, Oracle SELECT FOR UPDATE (WHERE id = ..) will lock the row as you select it, and anyone else trying to access it will block. Voila, no more table locks.

That still wont scale hugely because you are still blocking at the DB level, instead of using application logic to ping DB data and make the business logic decisions at the app layer.

Either way, hibernate can work with whatever refactoring you do, and it does add a good level of DB independance. I think a greater advantage is that if you change your data model (i.e. add fields) you dont have to rewrite SQL. That is nice!