What is the deafult LockMode in Jmix 2.0 in different situations?

Support
#1

Hi
I understand Jmix 2.0 is using the Jakarta persistence lock mechanism directly. My question is, if I am not explicitly mentioning any lock mode in my data manager, in the following scenarios, what will be the locking mode used by default if none of the lock modes is used?

  1. when the list of entities opened in a list screen, e.g. list of sales orders
  2. when an entity is opened to edit in the detail screen e.g. salesOrder no. 20
  3. when the collection of customers is loaded in salesOrder detail screen
  4. when a collection of products is loaded in a controller or Spring Bean.
#4

If you don’t call lockMode() in DataManager, then no any lock mode will be passed to JPA EntitManager. So if your entity is Versioned, JPA will provide optimistic locking for loaded entities. Otherwise, no locking behavior will be provided by the application.

#5

Yes, the entities are versioned. In that case, in a detail screen, will both Instance and collection containers load the data in Optimistic lock mode? How can I use lock mode in xml screen (e.g. detail screen, collections are opened in READ mode), do you want to share a code snippet?

#6

Yes.

The LockModeType provided when loading an entity works only within current transaction. So it won’t affect saving entities in views.

If you need pessimistic locking in views, use the Jmix pessimistic locking feature - unlike LockModeType it works on the application level irrespective of database transactions.

#7

Thank you Konstantin for clarifying. One more question, when I am using datamanager in a SpringBean, I haven’t used any lock mode unlike what I used in my CUBA projects annotation of @transactional (readonly = true). While I think optimistic lock will be fine, do I need to use the lock mode while loading or i don’t have to worry about it as Jmix is loading in optimistic lock mode by default whether it is loaded in a screen or in a service bean?

#8

I’d recommend using transaction demarcation with @Transactional as you are used to. And rely on versioned entities for optimistic locking. There is no need to provide LockModeType unless you want to lock some rows in the database for some sophisticated piece of business logic.

#9

Thank you so much Konstantin.