Doubt on the level of lock and concurency

[vu lee]

Suppose a CMP entity bean called EntityBeanA contains a map and a
method called modifyMapElement() which has transaction attribute
of 'require'. If a method X()--which is already in a trasaction--of
another stateless session bean invokes method modifyMapElement() to
modify an element in the map, until the transaction has been either
commited or rollbacked what is being locked in the entity bean to
prevent data inconsistency (eg. prevent others from reading the
content of the map) ? Is it the EntityBeanA or just the map or
something else? If the answer is EntityBeanA, would that degrade app
performance?

[Miki Muzsi]

First, what would you do with a map as member of an entity bean?

Second, transactions relate to databases. If you call a method (in a transaction) that would modify a member variable a map (say of a statefull session bean, 'cause there you would have typically maps as member :-) ), even if the transaction rolles back, the map remains changed! Unless you don't implement SessionSynchronization interface, and put something in the afterComplete() method.

Miki

[vu lee]

Thanks for your response, but I am asking about the level of locking. If an entity bean instance holds a state of a particular record in the table, the whole record will be locked or just a field of a record being locked? For database, normally the whole record will be locked. For EJB, if the whole entity bean instance is being locked, others clients who want to access the bean state will have to wait.

[Miki Muzsi]

Non- reentrant beans are single threaded. Which means only one client at a time can execute business methods on the bean. SO the whole bean is locked.

Reentrent beans would allow but usually they are "tricky" to program since concurent situations can occure. You can read more on this issue on pg. 189.

Miki

[Roger Chung-Wee]

Thanks for your response, but I am asking about the level of locking. If an entity bean instance holds a state of a particular record in the table, the whole record will be locked or just a field of a record being locked? For database, normally the whole record will be locked. For EJB, if the whole entity bean instance is being locked, others clients who want to access the bean state will have to wait.

A bean instance will always run in a single thread which the Container assigned on receiving the client request. A component business request will cause the Container to:

- start a transaction
- activate a bean instance to service the request by calling ejbActivate()
- tell the DB to lock the row to anyone else but the Container
- load the bean with the entity state from the DB by calling ejbLoad()
- run the business method(s)
- update the DB by calling ejbStore()
- end the transaction
- tell the DB to release the row lock
- passivate the bean instance by calling ejbPassivate()

[Miki Muzsi]

Roger,

Couple of minor corrections to what you have described:
- first activate a bean instance to service the request by calling ejbActivate()
- second start a transaction
- tell the DB to lock the row to anyone else but the Container
- load the bean with the entity state from the DB
- call ejbLoad() (ejbLoad () is a callback function called after the entity bean has been populated with right data )
- run the business method(s)
- call ejbStore() (ejbStore() is a callback function called before updating the database)
- update the DB
- end the transaction
- tell the DB to release the row lock
- passivate the bean instance by calling ejbPassivate()

Miki

[Roger Chung-Wee]

Yes, I think you are right about ejbActivate(): it must be called before the JTA transaction has started as this method runs without a transaction context.

[Karthik Guru]

The entity bean pool is likely to have mutiple beans that share the same primary key. There is probably another thread executing the same business method on that bean. When / what is suspended in this case?

[Roger Chung-Wee]

The container must prevent concurrent access to a bean in the same transaction context. Here is how it might be done.

The container runs a component business request in a single thread, utilising a bean instance from the pool. Should another business request be made at the same time on the same bean type, another thread is assigned to that request and another bean instance pulled from the pool to service that request. If there are no more instances in the pool, and the container cannot create more, the container can serialize requests until an instance is available.

This is quite different compared to a non-pooled bean, ie a stateful session bean, as a second request will cause an exception to be thrown by the container.

But the container might actually allow more than one thread to process a bean instance simultaneously if they have different transaction contexts. This is safe because concurrency problems will be prevented by the DB row locking. This also means that it is the transaction isolation level that dictates the level of concurrency protection, not the EJB container.

I get the feeling that the default isolation level for many containers is TRANSACTION_READ_COMMITTED, can anyone confirm this.

[Karthik Guru]

Originally posted by Roger Chung-Wee:
This is safe because concurrency problems will be prevented by the DB row locking. This also means that it is the transaction isolation level that dictates the level of concurrency protection, not the EJB container.

I get the feeling that the default isolation level for many containers is TRANSACTION_READ_COMMITTED, can anyone confirm this.

Hi Roger,

I wonder how this works. So if trans-1 obtains a row lock on <some_row>, it will get to update the row. trans -2 will block till trans-1 is complete and releases the lock.Then trans-2 will get the lock and will update the same row <some_row>. So the last update always wins?. Is that the way DB locking works?

[Roger Chung-Wee]

Yes, this is correct. This topic has some useful information.
https://coderanch.com/t/302388/JDBC/java/JDBC-manually-commit

[Karthik Guru]

I'm still a little confused. I guess oracle database must be supporting optimistic locking right? I mean there are on locks actually, everybody is free to read and write except that the row timestamp/version is checked before doing an update. Now if trans-1 and trans-2 get to read the rows and trans-1 gets to update before trans-2. Say I have READ_COMMITED (oracle default as you mentioned) as isolation level. So trans-2 will get to see the updated row before it runs its update. The timestamp it read upfront wouldnt match the current timestamp and the update will not go through?.