I have one desktop application (built in Swing) and two web applications (built on Struts and hibernate framework) that are sharing same database. Basically all data manipulations and insertions are done by desktop application remotely connecting to database while the web applications are mainly used for presenting data to the user and also have some download and mailing operations.
For now, each of the three applications create their own database connection from the single database and perform their own set of operations and then close them when not needed.
Although, I haven't encountered any performance issue or may be I haven't realized it even if there are any. But still, this kind of architecture appear to me a bit clumsy and complex. Therefore, I have decided to re-engineer these applications.
For database operations, I am considering for creating a set of web services that will perform the DDL or DML operations. My applications will hit these web services according to the operation they want to perform and get the result.
So in first place, I want to know if exposing the DB operations through web services are recommended considering the fact that it also have DML operations. Any other ideas that can improve current solution are also welcomed.
Related
Two Spring apps each use jpa to control a single database.
Each Spring app must use a single database.
Will spring.jpa.hibernate.ddl-auto = update work properly?
In my opinion, having 2 applications using directly the same database is a poor design.
Here is a quote from this sofware engineering answer
The more applications use the same database, the more likely it is
that you hit performance bottlenecks and that you can't easily scale
the load as desired. SQL Databases don't really scale. You can buy
bigger machines but they do not scale well in clusters!
Maintenance and development costs can increase: Development is harder
if an application needs to use database structures which aren't suited
for the task at hand but have to be used as they are already present.
It's also likely that adjustments of one application will have side
effects on other applications ("why is there such an unecessary
trigger??!"/"We don't need that data anymore!"). It's already hard
with one database for a single application, when the developers
don't/can't know all the use-cases.
Administration becomes harder: Which object belongs to which
application? Chaos rising. Where do I have to look for my data? Which
user is allowed to interact with which objects? What can I grant whom?
Upgrading: You'll need a version that is the lowest common denominator
for all applications using it. That means that certain applications
won't be able to use powerful features. You'll have to stick with
older versions. It also increases development costs a bit.
Concurrency: Can you really be sure that there're no chronological
dependencies between processes? What if one application modifies data
that is outdated or should've been altered by another application
first? What about different applications working on the same tables
concurrently?
What I would suggest to you is to create a service layer which will be responsible for dealing with database access. This service can then be accessed by differents ways (a REST webservice might be an option).
#Vinod Bokare comment is correct, you must create jar of POJO's and use in both projects,
and #Heejeong Jang, It will be okay if each of our Spring apps has different table areas for insert, update, and delete.
Is Hibernate less effective in some environments, like a polygot company where several distributed systems are accessing the same db? If Acme Company has a python website reading from and writing to the same database as a java web app (web services), will Hibernate be a poor choice for the java web services app? In other words, does Hibernate caching and session management assume all db transactions for Acme will be using Hibernate? Do I need to be sensitive to certain ORM concerns at a company where several programming languages are writing a lot of updates to the same data concurrently? Is Hibernate more advantageous for a strict java shop using a java ee app server for nearly all of its business operations?
Hibernate does have some performance overhead over pure JDBC, but if you're using it cautiously it should be fine for most of use cases.
Hibernate does not assume that it handles all operations itself. The only thing I would worry about is second level cache if you need it. You won't have a way to keep it in sync if other apps access the same DB (but you don't have to use it).
Having said that, I must add that having multiple apps write to the same DB is not a good practice. I'd rather create one app that handles this DB and have others communicate with this one - this way it's much easier to keep the database consistent.
It is getting burdensome on my team to prototype tables in MySQL that back our Java business applications, so I'm campaigning to use SQLite to prototype new tables and test them in our applications.
These tables are usually lightweight parameters, holding 12 to 1000 records at most. When the Java applications use them they are likely to be doing so in a read-only capacity, and typically the data is ingested in memory and never read again.
Would I have a problem putting these prototype SQLite tables out on a network, as long as they are accessed via read-only and in small volume? Or should I copy them locally to everyone's machines? I know SQLite does not encourage concurrent access on a network, but I'd be surprised if more than one user would hit it a the same time given the number of users and the way our applications are architected.
If you are using a three-layer architecture, only the application server should have access to the database server. Therefore, you should have control over the connections (i.e. you can create a very small connection pool).
Embedded databases are not suited for lots (hundreds) of concurrent connections. Nevertheless, having into account the amount of data and that you will only focus on read-only queries, I doubt that would be a problem.
A major problem I foresee is that you can have serious problems in terms of SQL dialects. Usually embedded databases use the ANSI SQL standard, but mySQL and others allow you to use their own SQL dialects which are incompatible. It's usually a good practice to have a unit test that runs all the SQL queries against an embedded database to guarantee that they are ANSI-compliant. This way, you have a guarantee that you can use your application (automatically or manually) with the embedded database.
I have database driven web site that needs more than one MySQL Sever to handle the expected demand
I also need to implement back up system (of some type) to keep data safe.
I'm using java but that that’s not critical
What options are available to me from projects out their
I'm thinking of daisy chaining project with the MYSQL server's somehow and then when one is busy go to the next and they all be written data to. I know they can measure time used they must be able to measure when they are in use.
You might want to look into clustering.
http://www.mysql.com/products/cluster/
How about deploying a Cluster in the cloud?
http://www.mysqlconf.com/mysql2009/public/schedule/detail/6912
I wanted to ask that what all things i should keep in mind in order to create a high performance STRUTS2 based web application. It is guaranteed that the site will have a high traffic (i.e. lets assume somewhere around 500,000 requests daily). Also there will be a decent lot of database accesses.
Please comment as i have decided of using the following frameworks (or suggest any better alternatives):
Struts2 + springs and hibernate
Jsp + jquery for views
DWR for ajax calls
Please suggest some performance tuning/enhancement strategies.
Thanks!
Couple of things you can do.
First:
the biggest bottleneck in a website is always the database connection. You will need to make sure that your database is running in a separate cluster and try to do more in each database session when using hibernate. The less DB connections you open/close the faster your application will be.
Use hibernate as much as possible because it has logic to cache queries and such. Also if you have the same information being used across the users session, put it on the session object so that you do not have to query the DB for that info multiple times.
Second:
Use the Spring IOC as much as possible. You should create "service" classes that will be doing your database querying and those classes should be created as singletons and injected into a constructor or setter via Spring IOC.
Third:
Make use of a tool like tiles or wicket. It will allow you to create layouts for your JSPs.
Fourth:
If you have data displaying on the page that takes a long time to load/query, go ahead and load the page with the other data that is fast and then load your slow data dynamically through AJAX. It will give the user the impression that they are receiving an immediate result.
Of course there are many other things you can on the server side. You might want to deploy the application across several node and use a load balancer to route traffic to the least busy node. The amount of caching at the proxy, app server, browser, and database you do will also significantly impact your performance.
Hope that helps!
Since you are using hibernate, you should also look into hibernate performance tuning for which there are lots of resources including these discussions:
https://stackoverflow.com/questions/2460342/books-and-resources-for-java-performance-tuning-when-working-with-databases-hu/2460466#2460466
Hibernate performance
Hibernate performance
Usual hibernate performance pitfall
Avoid bottlenecks in your app design - see these tips from Yahoo.
Run the web server, application server and database server on seperate hardware clusters.
If the performance isn't good enough profile to see what is slowing it down; if there is a bottleneck in the code fix it, otherwise add hardware until it is fast enough.