do you like my beans?

[timasmith]

I have an application with a lot of generated SQL, data access, mapping
and client object code.

I am not ready to hand that over to JBoss or other servers and
primarily wish to use an application server for executing SQL and
business logic in a service orientated fashion.

Some reference data caching but *no* session management.

With that in mind I have been testing using entity beans only.

My typical entity is not actually tied to any database, caches nothing
and just executes SQL.

I use an entity bean since it persists forever and I am guessing it is
much lighter on the server to do that instead of creating a session
bean per client. Why have 1000 beans when you could have one?

I assume there is no concurrency issues since everything is a local
variable - except for the data access objects which are never written
to - they just have methods executing connections, sql, etc.

Does this sounds reasonable? Perhaps I could make my beans read only
and that would further enhance performance.

thanks

Tim

 

[Jon Martin Solaas]

I have an application with a lot of generated SQL, data access, mapping
and client object code.

I am not ready to hand that over to JBoss or other servers and
primarily wish to use an application server for executing SQL and
business logic in a service orientated fashion.

Some reference data caching but *no* session management.

With that in mind I have been testing using entity beans only.

My typical entity is not actually tied to any database, caches nothing
and just executes SQL.

I use an entity bean since it persists forever and I am guessing it is
much lighter on the server to do that instead of creating a session
bean per client. Why have 1000 beans when you could have one?

I assume there is no concurrency issues since everything is a local
variable - except for the data access objects which are never written
to - they just have methods executing connections, sql, etc.

Does this sounds reasonable? Perhaps I could make my beans read only
and that would further enhance performance.

thanks

Tim

It is generally considered good practice *not* to expose entity beans to
the (remote) client, mostly for performance reasons, but also to avoid
binding the client to one particular persistence platform. Read up on
the Session Facade pattern.

If your application requires each client to have a persistent connection
to one stateful session bean throughout their lifetime you have made a
mistake in the design (or you have had a very good reason to design that
way). Try to find out more about Stateless Session Beans and bean
pooling in the appserver you use. 1000 client may very well be served by
a relatively small number of pooled session beans (depending on the way
the client interacts and many other things ...) There is not supposed to
be a 1-1 mapping between http-sessions and session-bean instances.