That's where the transaction commit options (A, B & C) defined in the EJB spec (1.1 and 2.0) come in. I can at least explain how things work with our Container.
If you use transaction commit mode B (which is pretty much the default that most application servers use for entity beans - at least for us :), then bean instances are put back in the cache as opposed to the pool. The difference here is that instances in the cache are associated with their pk (and maybe state - that is, state of the persisted fields if you use Option A). So at the start of a transaction when using option B, the Container already knows the identity of that instance by virtue of its primary key. So the Container can avoid moving an instance from the pool ( which contains arbitrary instances; that is, instances not associated with a pk) and associating it with the pk and instead only call the ejbLoad() to move that instance in the cache to the 'ready state'. If there is no instance in the cache (we fill it lazily), then an instance is transitioned out of the pool, associated with an identity - its pk - and finally followed by a call to the ejbLoad() to move to the 'ready state'. At the end of the transaction, bean instances could move from the 'ready state' back to the cache or pool depending on the limits set by the deployer for the number of instances possible in the cache & pool. In Option C, there is no cache - that is, there is only a pool. With Option A, at least in our AppServer, the AppServer could act as a pure middle tier data cache. Since the AppServer has exclusive access to the database, the instance is not only associated with its pk but also its state. Thus if an instance is present in the cache, then the Container can avoid an ejbLoad (and even an ejbStore() if no modification took place). -krish > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of ejblist ejb > Sent: Thursday, March 07, 2002 12:06 AM > To: [EMAIL PROTECTED] > Subject: EJB - Primary Key > > > Hi : > > I was just reading the EJB Specs and was just wondering about the primary > key concept.Lemme Give you the scenario which i was thinking. > > 1. Let's say we create an Entity bean do some business operations and log > out of the system. > 2. Again we get a reference of the previously created bean using the > home.findByPK() method which returns me the stub of the remote interface for > further operations. > > Is it that the container goes to the pool (let's assume the ejb instance is > returned back to the pool) picks up any arbitrary bean instance, queries the > Datastore, get the data, initialize my bean instance,attach the instance > with the remote object or is there any other flow of the process. > I just want to know the internals as to what actually goes behind the scene. > > Thankx > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
