Scenario: In any kind of online Reservation application there is possiblty that people may acesses the application at the same time.
Because of this there could be a concurrency issues in that perticular application.
Problem:
In this case, if one or more people accessing the application at a time then there is a problem of concurrency issue.
To solve concurrency the issue we have two solutions
1) Java Concurrency at Client level
2) JPA Optimistc or Pessimistic Locking at persistence level
If the database contains 10 millions or more records then which one is the optimal solution?
Performance issues and Concurrency issues are two different problem domains altogether. Its better not to mix both.
Regarding concurrency issues:
Java Concurrency or Multi threading may be of very limited use in a online reservation system. To avoid problem of lost updates, you must use either JPA Optimistic Locking (preferably) or Pessimistic Locking. That's because if multiple instances of your application are running in parallel (or multiple threads) then its impossible to avoid lost updates using JVM level thread-safety techniques.
You can refer to the below tutorials:
JPA Optimistic Locking - Oracle Blog
The Java EE 6 Tutorial
It completely depends on the application. If the Datamodel, not complex and not huge then the JPA Optimistic Locking is an optimal solution.
Both Java & Database Concurrency have there own advantages and disadvantages.
Database level:
Advantage:
1) its easier to implement and also for maintenance.
Disadvantage:
1)If the database contains huge and complex data then it may causes deadlocks and timeouts.
Java Level:
Advantages:
1) Better resource Utilization
Disadvantages:
1) Debugging & Testing very complex.
2) There is a possibility deadlock occurence.
3) Difficult to implement in Java Programming.
4) An Element of risk involved with a bad design.(Starvation)
5) it's not portable from one environment to another environment
ref: java Concurrency vs JPA concurrency
ref: database vs user level
Related
I am a beginner in NodeJS world coming from several years working with relational databases in Java / Hibernate.
I would like to use Node for a project, and have spent some time researching about frameworks / ORMs that handle proper database transactions/concurrency such as:
Ensure ACID transaction blocks (operations set is completely executed or not executed at all)
Deal with concurrency, i.e. leveraging strategies as optimistic / pessimistic locking
I've looked into some promising ORMs like Sequelize and Waterline
as the most promising ones.
Waterline looks good, but lacks both features mentioned above.
Sequelize looks much more comprehensive having proper ACID transaction handling. Support for locking and concurrency is absent.
I would like to ask to NodeJS experts about specific patterns or strategies as well as any modules implementing how to deal with a highly concurrent load at database level, cleanly retry failed transactions or ensure data integrity in a HA system.
I understand how and what happens when we use MODE_THREADLOCAL and MODE_INHERITABLETHREADLOCAL in Spring Security Strategy. What I don't understand is, why would someone use MODE_THREADLOCAL over MODE_INHERITABLETHREADLOCAL.
Is there a memory impact with using one over the other. If so, is it
significant enough?
What is a typical business/functional usecase for using MODE_INHERITABLETHREADLOCAL?
Any performance different with using one over the other?
The memory impact of using the two is negligible
In some environments, it is common to spin up new Threads to do background tasks. Sometimes developers do not want the Thread that is created to contain a SecurityContext automatically. In these instances, MODE_THREADLOCAL is preferable. If you spin up a task on behalf of the current user, then it may be desirable to propagate the SecurityContext. In this instance MODE_INHERITABLETHREADLOCAL would be preferrable.
Performance between the two strategies is negligible
I have a pool of the threads and they do the bunch of the operations with the database. However the amount of the threads is huge so it's very possible that 2 threads would like to use the same record from the database at the same time.
In ado.net I'd use transactions to handle this situation.
What should I use in entity framework to avoid mentioned problem?
I have been using CouchDB on some prototype applications and it has been brilliant, very easy to use and extremely quick. I was wondering if anyone has been using it in production and have any views on it's reliability, performance suitability for operational management etc ?? I am considering using it to support a service layer and would make use of its replication functionality.
Any comments/experiences would be most welcome.
I've used CouchDB for a few small in-house applications - it's been very stable and I've had no serious complaints. Setting that aside, a few small gripes -
1) Databases can be synchronized, but not nodes. That is, if you have four servers and twenty databases, you have to specify each server, and each database to synchronize. A minor gripe, but I prefer less management to more.
2) Since databases are append only, a database with a bunch of activity gets really big really quickly. Compacting fixes this, but isn't exactly fast, especially on big (e.g. 20 gigabytes) database. Scheduling compact for the weekends solved this, but doing that is probably less of an option for high availability applications.
3) Javascript is the de facto view language. What is not well advertised is that since CouchDB is written in Erlang, it also supports Erlang views, which are faster as they are "native". For applications doing a lot of operations in views, Erlang probably makes more sense.
Setting those minor issues aside, I'd wholeheartedly recommend it.
CouchDB ships in Ubuntu and is a fundamental component of the Ubuntu One service.
I have been using CouchDB on some prototype applications and it has been brilliant, very easy to use and extremely quick. I was wondering if anyone has been using it in production and have any views on it's reliability, performance suitability for operational management etc ?? I am considering using it to support a service layer and would make use of its replication functionality.
Any comments/experiences would be most welcome.
I've used CouchDB for a few small in-house applications - it's been very stable and I've had no serious complaints. Setting that aside, a few small gripes -
1) Databases can be synchronized, but not nodes. That is, if you have four servers and twenty databases, you have to specify each server, and each database to synchronize. A minor gripe, but I prefer less management to more.
2) Since databases are append only, a database with a bunch of activity gets really big really quickly. Compacting fixes this, but isn't exactly fast, especially on big (e.g. 20 gigabytes) database. Scheduling compact for the weekends solved this, but doing that is probably less of an option for high availability applications.
3) Javascript is the de facto view language. What is not well advertised is that since CouchDB is written in Erlang, it also supports Erlang views, which are faster as they are "native". For applications doing a lot of operations in views, Erlang probably makes more sense.
Setting those minor issues aside, I'd wholeheartedly recommend it.
CouchDB ships in Ubuntu and is a fundamental component of the Ubuntu One service.