Hello,

We are planning to use Struts in conjunction with Hibernate. Our application needs to support hunderds of forms and will process 250 forms per second (each one has about 10 fields). The design we have in mind would have Struts FormBeans that are mapped with the DB through Hibernate. This application would then be deployed in a clustered environment.

Each form consists of a set of 10 subpages that a user has to walk through to complete the form. Struts allows us to define one JavaBean for all ten pages (containing approx. 100 getters and setters). Each time the user goes to the next page, the data has to be stored in the DB. When he clicks "back", he can makes updates that are also saved in the DB upon clicking "next" again. I have the following questions:

Would Hibernate be able to handle such a load (please be very honest)? What are the pitfalls?

How do we handle the page chaining and calls to Hibernate? Do we open and close a Hibernate session with each new page? Is it better to keep the session with Hibernate open for as long as the user fills out the form? What about threads?

Please let me know what you think would be the best approach for such an application. Thank you!

Thomas

Direct mapping of form into DB seems not to be the best design but whatever.

Don't let hibernate session open between user filling out, it will let the DB connection open and your app will be limited to n user (n = allowed connection to DB).

Two ways:
* open session and close it between each page
* keep 1 session in user session but disconnect it (see section 14.4 of the reference guide.

It seems that the second solution is the best choice for you.

What's wrong with this? Shouldn't we avoid additional layers in a high-performance application? What would you suggest?

I'm not sure if ORM is what you are looking for. If the forms map 1:1 to database tables, I'd try things like Oracle Forms or other data application design tools. There is not much value you can get from Hibernate in this case, only abstraction of the data access metadata, so you may switch databases easily. I guess complex form validation rules and flow control are much more important in your case.

Christian,

And what about caching and Transaction support that comes with Hibernate?

Thomas

Well, the transaction support is basically only a wrapper for the JDBC or JTA/CMT transactions, which is only a portability win (and a smaller API than JTA). The cache of course can help. But I think that many form-oriented frameworks (I don't know much about this area though) provide a cache too.

I just had a 10 minute look at Dataphor some days ago, sounds like it may be better suited for your task. Its not Java though :)

http://www.alphora.com/tiern.asp?ID=DATAPHOR

This "trivial" table CRUD operation stuff is actually an area where I don't know of any mature Java solution. I also think that this is one of the reasons why the "J2EE is too complex" discussions pop up. If you have the time, you can check out Naked Objects or the OJB Console (try Google for both). A Hibernate solution in this area would be great.

I remember some people working on automatically generated user interfaces from Hibernate metadata, including validation, but it has been quiet in the last couple months.

I don't like to say that Hibernate can't be used for this, when it can, but I would echo what Christian says. If your application is fundamentally table oriented, and not at all object oriented, then ORM is overkill. If you are not using inheritance and associations - and you are not writing complex OO queries - then you are using about 5% of Hibernate's functionality.

We try to be very honest here and not try to push our product where it might not be appropriate. :)

P.S. I would disagree with Emmanuel and say that a session open for the whole "form" would be reasonable, as long as you disconnect() the session between requests.

P.P.S. I also don't consider 250 requests per second to be an especially high load. Hibernate is never the bottleneck anyway, it is the database or the UI.

I'm a three tier school guy, it explains my remark. We are in the Application Architecture forum, aren't we ;-)
However, If your application is intended to be Quick & Dirty (no offense, lot's of apps are indeed) and not be updated and evolved that much, then Christian's advice are good.

I saw Hibernate to be adapted to RAD when you design your object model, and generate your DB model : this is very agile.

OK. Most of you seem to agree that Hibernate may be overkill for form data storage. The reason why I tended towards Hibernate is the use of a mapping file to configure the formbeans with the database columns. (Remember we have litteraly hunderds of beans to manage). As a last point, can anybody point me to an Open Source Java solution that might deliver similar advantages? I am a bit anoyed with the fact that we are creating form beans and that we then have to convert them to DTO's.

If you want my opinion, I would say ditch the formbeans. (I am not a fan of Struts.)

I suppose if you absolutely *have* to have them, and you want to persist them direct to the database then maybe Hibernate *is* the easiest way. I'm going through my head thinking of alternatives that won't require three times as much code and I can't think of anything much. Even ibatis or something like that is more code since you have to write the SQL yourself.

Guys, is there anything simpler?

There is an application called dataGlue that attempts to match form input with the DB. Seems like a possible fit for your application. The only hitch is that there is no layer for Hibernate. Although the author is very interest in help.

Right now JDO is used as the ORM.


http://www.geocities.com/danbunea/cv/dataglue/

It must be possible to implement workflow framework to parse XML file and to generate source code or to interpret this file.
It will take a lot of time if you need very clever workflow, but can be trivial in some cases:

<form table='Person' name="firstForm" action="nextForm" >

<text field='Name'
type='string(256)'
required='true'
>

<en> my name </en>
<lt> mano vardas </lt>

</text>

<text field='email'
type='string(256)'
validate='email'
required='true'
unique='true' >

<en> my email </en>
<lt> mano pastas </lt>

</text>

</form>

<form name='nextForm' action='lastForm' ...

I do not know any OSS project for this stuff, but it must be possible to find some workflow implementation for web forms.