Somebody recently asked that here somewhere, but I can't find it. Technically, yes - an EJB is a data entity in its own right, and nothing in the spec actually REQUIRES that it be connected with a database (though Entity Beans do require SOME type of persistent storage to be fully functional). Practically, I don't recommend it, since one of the reasons why you'd want to use an EJB is to better maintain the integrity of the database by using EJB's ACID properties. If 2 different EJBs represented the same table row and they had overlapping fields, there's a good change the DBMS could be corrupted and/or the EJB runtime environment would display inconsistent data.
An IDE is no substitute for an Intelligent Developer.
Joined: Mar 12, 2001
Hi Tim, You are right. My real problem is, 2 concurrent transactions acting on a CMP, which imply same row. When the 2nd Txn tries to commit the data modified by that Txn, at the point of commit an exception is thrown. To workaround I caught exception thrown at this commiting point & again tried to commit it in a loop. This soln works. But is not the proper way to do it. Do u have any suggestions ?
Hello Shivaji Mandating that each bean can service only one client at a time could result in bottlenecks. To boost the performance, we could allow the containers to instantiate multiple instances of the same entity bean class. This would allow many clients to concurrently interact with seperate instances, each representing the same underlying entity data. This may lead to data corruption .. ( THATS WHAT YOU ARE FACING ) . To achieve entity bean instance cache consistency, each entity bean instance needs to be routinely synchronized with the underlying storage.The container synchronizes the bean with the underlying storage by calling the beans ejbLoad() and ejbStore() callbacks. The frequency with which beans are synchronized with the underlying storage is dictated with transactions Transactions allow each client request to be isolated from every other request.They enable clients to believe they are dealing with a single in-memory bean when infact many instances are behind the scenes.Transactions give clients the illusion that they are the only ones accessing the underlying data when infact many clients are touching the same data. I hope you got it ... use Transactions.