What about replacing Entity Bean layer with Java custom persister (no EJB)
2 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Massimo_Bartolucci
Posted On:   Friday, April 13, 2001 01:22 AM

We are developing an application based on houndreds of table data almost all on-line updated. The backoffice is Oracle. WebSphere is the application server. The front-end is JSP/Servlet based. For many reason linked to data architecture, active database role in the application (stored procedures and triggers), performance, error handling and development speed, we decided to avoid using Entity Beans to make data persistent: but we want to preserve the container management of the transactions using Session Beans. So we perform persistence through a custom framework hooked to our bulk object architecture. The bulk objects are passed from the client to the session bean methods that eventually call a Custom Persister that knows how   More>>

We are developing an application based on houndreds of table data almost all on-line updated. The backoffice is Oracle.

WebSphere is the application server. The front-end is JSP/Servlet based.

For many reason linked to data architecture, active database role in the application (stored procedures and triggers), performance, error handling and development speed, we decided to avoid using Entity Beans to make data persistent: but we want to preserve the container management of the transactions using Session Beans.

So we perform persistence through a custom framework hooked to our bulk object architecture. The bulk objects are passed from the client to the session bean methods that eventually call a Custom Persister that knows how to make the bulk objects persistent: it is not EJB only JB (no remotization needed) but works in the frame of a container generated and handled transaction (connection got by data source lookup on JNDI).

Is it this approach legal? I look up JDBC connection from DATA SOURCE: am I garanteed that doing so from different methods in different session beans called in chain from the same starting session bean method, the connection (and so the transaction) is always the same?

What about performance?



Thank you in advance

   <<Less

Re: What about replacing Entity Bean layer with Java custom persister (no EJB)

Posted By:   Michael_Herrmann  
Posted On:   Friday, April 20, 2001 03:56 AM

Hi Massimo,
in my current project we use a similar approach with BEA Weblogic. Our data-design is relatively simple, and most data is read once, so that we don't miss caching of Entity-Beans etc. We only need the transaction-handling and resource-pooling of the application server. For the problem of transaction-management: in my understanding (which mainly comes from Weblogic) the connection-handling is separated from the transaction-handling. So if you set the bean-methods-transaction-attribute in the Bean-descriptor correctly, the called Bean-methods should "inherit" the transaction of the calling Bean-method. I would set the transaction-attribute to "required", (i.e. not to "required new"). I think this attribute is not Weblogic-specific, but I'm not sure. Then the chained-Bean-methods should run in the same transaction. With Weblogic, we use a connection-pool and it is in no way ensured that we always get the same connection, so I think connections and transactions are independent. But this could also depend on the Application Server... Maybe someone else knows more? Hope this helps anyway and good luck with your huge application!

Re: What about replacing Entity Bean layer with Java custom persister (no EJB)

Posted By:   AlessandroA_Garbagnati  
Posted On:   Friday, April 13, 2001 02:54 AM

Massimo,

Very interesting question. I can give you my personal opinion about it, but I hope to see many follow up to this message, maybe from people more qualified than me.

Your appreach looks 'legal'. Theoretically your connection (and so your transaction) could be maintained for the entire life of your chained session beans (I think you're considering stateless session beans). Unfortunately, I'm afraid that the real and final response is strictly connected with the way your code is designed and it will be written.

Performance... even more difficoult to judge. I've seen, recently, an architecture that was not using any entity bean and was just relying on session beans. The database was extremely huge (not kidding) and the type of access was more a multidimensional OLAP than a 'simple' OLTP, and, for the architects that were involved in the project, entity beans were not the right 'tool'.

What I think is that you're not just bypassing entity beans and accessing the database directly with your session beans. You have to provide persistence services, database locking strategies, isolation level, patterns for accessing and interacting with the data and, in addition, you are going to loose the read/write caching services that are offered by entity beans, relying only on the caching that it's offered by the database. Nothing it's impossible, but definitely it's not an easy task.

Personally, I do not like this approach, because it's adding a lot of complexity to the entire development and, consequently, can make even more difficoult to maintain the code.

Said so, I think that it's possible that writing your own 'layer' you can reach better performance on your application.
About | Sitemap | Contact