• Post Reply Bookmark Topic Watch Topic
  • New Topic

how to choose CMP Entity Bean concurrency strategy for use cases?

 
Robert Strong
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in Weblogic8.1, CMP Entity Bean support optimistic and database concurrency strategy, and cache between transaction.

optimistic concurrency is best to be used with cache between transaction, but with an overhead to add a timestamp column in the table of entity bean.

with database concurrency, cache between transaction cannot be used.

for a use case, like a customer make an order, which consists of several items he purchased. for the object graph of order and items CMP entity bean. which concurrency strategy shall I use? the customer's orders and items are unlikely to be reused, it doesn't benefit fro being stored in cache. so I should choose database concurrency instead of optimistic concurrency?

for a use case like, a customer request a quote of an insurance policy. the policy entity bean is used everytime a customer make a quote request. it might be need to be stored in cache, so that each customer's quote request may be processed in application server without database hits. in this case, optimistic concurrency strategy should be used with cache between transaction?

any help appreicated!!
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Robert,

Just my opinion: many organizations chouse J2EE because of its build once run everywhere promise. Of course by now we figure out that with EJB this is mostly an utopia :-) However if an organization doesn�t demand this, then one has the option to chose between other vendor specific concurrency strategies like those you�ve mention. Now if you have this freedom, I�d like you to step back a little bit and answer to a more exclusive and generic question: why should one use the database concurrency strategy for? Can you think of any requirements that demands this? As for me I can think of only three:
  • If the database is updated by other external process the cache holds stale data. The ejb load-and-store cycle is more appropriate for this scenario.
  • The "inconvenience" of catching the exception that the container throws if data was changed by other transaction. This could or could not be a problem, unless it has the probability of "happening very often".
  • It�s vendor specific.


  • Of course timestamp column overhead that you�ve mention (which could be replaced by a representative set of columns) could be another reason.
    Looking at this problem from a business requirements standpoint, can you think of any use case that cannot be satisfied by the optimistic concurrency strategy? Well I can�t see any, but I might be wrong though. Finally we might conclude that excepting the situations I�ve mentioned above, optimistic concurrency strategy should actually be the preferred choice, because it fulfills all the use cases that the load-and-store cycle does. Besides it provides the caching between transaction advantages and this could make a lot of difference though.
    To answer to your questions I would rather chouse the optimistic concurrency strategy for both scenarios. It can�t hurt though and your system might change later on in such a way that this strategy will prove benefic.
    Regards.
     
    Robert Strong
    Ranch Hand
    Posts: 84
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    hi, Valentin

    thank you for your quick reply, so basically optimistic currency + cache between transaction is used in most scenarios. but how do you choose optimistic concurrency mechanism? do you prefer to use timestamp, version column, modified or readonly? I've been told to use timestamp for most cases, what do you think of it?

    thank you again!!
     
    Valentin Tanase
    Ranch Hand
    Posts: 704
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Personally, admitting I have the freedom of choice, I�ll go with the timestamp column design. I�ve seen a lot of times tables designed to record the time of last update along with the name of the user that updated the data. Hence your timestamp column could be really handy.
    Regards.
     
    Roger Chung-Wee
    Ranch Hand
    Posts: 1683
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Here is a useful post.
    http://www.coderanch.com/t/302388/JDBC/java/JDBC-manually-commit
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!