Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How "synchronize" or lock a Collection returned from an EntityBean?

 
Dan Bizman
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I have an EntityBeanHome with the method findByAge() that returns a collection, is there any way to do the equivalent to synchronizing on that collection?

I ask because if the collection is returned to one calling object which then iterates over it at the same time that another object tries to add to the collection (i.e. add a new entity bean that would fit that search criteria) is there a way to:

1. have the collection locked as it would be with synchronize? (so the other caller has to wait, since they also execute in synchronize or whatever)

2. Will the collection be updated when a new entity bean is added that fits that criteria?
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dan,

No there is no way to do something like that. In order to run a finder the container will get a bean instance from the pool and will return a list of remote interfaces. If in the mean time the database gets updated there is no way for the container to miraculously insert the new beans into the list. Neither can this be achieved programmatically, unless you don�t call the finder again and check if the list is different, etc. Usually the data consistency is guaranteed using appropriate transaction levels, but this works very well for use cases that run within one transaction only. If a use case needs to span more than one transaction (like customer booking a fly ticket) then one needs to come up with different trickeries like the Version Number design pattern. In your case the simplest (but unrealistic) solution would be to have the finder as well as the client looping logic running within the same transaction that has a high level of isolation. This way your app can forbid other transactions to update the data, while the first client loops through it and you don�t need to worry about the "new arrivals". This would probably imply that the client should start the transaction, which will in most of the cases is unacceptable. It will also result in designing a very inefficient transaction model that can block the database access for a long time and your system won�t scale well either. It might be acceptable though in some very specific circumstances, when this transaction runs very rarely, like a sysadmin task that needs to lock the data in order to update it (just making something up :-))
You might also need to provide little bit more business context here maybe we can come up with better solutions.
Regards.
 
The glass is neither half full or half empty. It is too big. But this tiny ad is just right:
the new thread boost feature brings a LOT of attention to your favorite threads
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!