As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
To guarantee only a single write-transaction per database/resource I'm creating a .lock-file which prevents other JVMs from starting a session.
However, I'm not sure how it is handled for instance in Eclipse if the Application crashed. I think I had to remove the file manually?! So, is this a common solution or do other solutions exist? I think a restarted application (after a crash) cannot be distinguished from a usual application, I think that is one thing which bothered me once or twice with Eclipse, which didn't show up a proper message that I had to delete the lock-file before restarting Eclipse. But I'm not really sure if that was the problem.
Ok, I might have another solution for write transactions which have to check for a transaction-log which is deleted for proper commited transactions. But well, the write-transaction is ussed after the check. Do other solutions exist? I can't think of any...
Databases have been handling transactions and isolation for a long time. I cannot for the life of me see why you'd see the need to reinvent this wheel. Have you not heard of JTA?
Have a look at Spring and its transaction managers. This problem has been solved better by others.
UPDATE: NoSQL means no ACID by design. If you need ACID, don't use NoSQL. You're adding complexity to make up for a poor design decision.
What does Eclipse have to do with this? It's an IDE. I presume that your users won't have to fire up an IDE to run your app.
You should really try and dodge this bullet.
But if you are using a dbms with the ability to use transactions back in the old days, this was one trick for application or user locks
You create a table e.g applicationLocks
Then you start a transaction and insert / update a specific record, but do not commit it.
Anyone else coming in after won't be able to because the row is locked, and you take some suitable action.
When the application closes, rollback.
If the application crashes, the connection will get closed and the transaction rolled back anyway.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a sort of unusual question, and I know it is a very controversial, but here it comes.
I have developed a few JSF applications in the past but these all limit the amount of users that can be servred about 5-6. This was partly because of a license based policy. I performed some tests with 20+ users and Selenium, and the applications went really slow. The problem was probably originating from the server's performance but still, I can't help to ask the following question:
Can a JSF application support a large number of users? My bet would be that the framework should allow it, however I can't think of any commercial website that uses JSF and can support thousands of users at a time. (If you could show me some that would be great!)
I ask this, because I have been asked to develop a larger system, and I would love to use JSF because I love it very much, however the recent performance tests gave me doubts. The lead programmer said it is only the server machine's perfomance that is the issue, but in that case, what kind of machine can support thousands of users logged in at the same time? The lead programmer is not the best of it's kind, that is why I want to hear a second opinion from SOF if you dont mind.
If there is any framework more suitable for extreme use please let me know which one it is, the only real constraint I have is that it should be Java based on the server side.
Again my apologies for the unconstructive question.
these all limit the amount of users that can be servred about 5-6
Not sure what the app's load or design are, but that sounds unbelievably low. JSF should be able to handle many 100s of users if designed right or even 1000s with the right infrastructure. JSF code runs with servlets and facelets - the framework is standard code on top of these, that has been optimized over time and gets JIT optimised at runtime.
E.g. With IBM Websphere Portal Server and Oracle Portal, the standard way to build customer portals and apps is via JSF. And they're used in massive installations.
Sounds like your past app(s) have some problem. I don't think you can blame that performance on JSF.
If you want an extreme number of connection is Java you might consider http://netty.io/ It is designed to support and has been tested for 100,000+ connections.
I suspect the bottleneck is not the number of connections you have but how efficient you serve up pages i.e. you JSF is particularly slow. If you optimise that I suspect you can handle more connections.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have to design a Java Application, which has database connectivity as well. I am unable to decide which database should i use? "PostgreSQL" or "SQL Server 2008". I want to know which has better compatibility with Java language? Also which one is more easy to use and implement?
This is a very subjective question and one that will likely be closed, but for what its worth, this is my opinion:
Both database servers are compatible with Java using JDBC and several ORM's such as Hibernate.
Instead of Java compatibility what you need to consider is:
Your resources (financially and computationally)
Your familiarity with one DBMS over another
SQL Server tends to be a bit of a hog for installation. For management tools your looking at SSMS, which can be a bit of a beast, but is very good at what it does.
PostgreSQL is lighter on the installation front. The PgAdmin III tool is very effective at what it does, and is, in my opinion, easier to use.
SQL Server's free editions have database limitations. It's paid versions do not, but they are expensive. PostgreSQL does not have any limitations for database size, and it's open source.
Both DBMS's have a vibrant community and help is readily available.
Hope this helps.
--Edit--
As a starting point for databases, each database server will be as easy as any other to learn on; although the tools that the server provides may temper the learning curve some.
Should I have to go back to square one and relearn everything again, heres what I would do:
Pick PostgreSQL. I would chose PostgreSQL to learn on as it is fully ACID compliant, has little tolerance for syntax errors, and provides exactly what you ask for in the result sets.
I would learn the command line utilities first, followed by PgAdmin III as it would give me the best possible exposure to the database, without holding my hand.
Read the documentation found on PostgreSQL.com and supplement questions with Stack Overflow, and dba.stackoverflow.com
DON'T PANIC. Learning a DBMS is a tall order, one that I have yet to complete. There are times when it is frustrating and hard. It will be easy to want to quit. Don't. Hang in there and keep trying, the rewards are worth it.
The PostgreSQL community is great, and the answers I have gotten, and seen on other posts here on SO are top notch. For some samples, check out any answer by a_horse_with_no_name and Erwin Brandstetter, I guarantee you will learn something.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm developing a Java application that communicates with a MySQL database in a server. The app should be able to read some data from an XML file and then insert the info read into the database.
I used to write SQL Statements directly to the Java code, but then a friend advised me to create a web service that does all the SQL stuff for the tool, and let the tool's only job is to read XML and send data into the web service.
My question is, does it deserve that effort? Why or Why not?
SQL in code is not recommended as it becomes difficult to maintain. The application is also tightly coupled to the database structure. Every time the database change (or you are moving to a new database) you need to make changes to your code and release again.
I don't think a web service is the correct answer here. I would recommend you try one of the following:
If your application uses a lot of tables and very high throughput is not critical, use Hibernate as an ORM tool. It has many features and can really reduce the time spent on data access.
If you do not have that many tables and you don't have the time to learn Hibernate, use iBatis. It will take you 30 minutes to grasp. It essentially allows you to put your SQL in a separate XML file, which it will read for you. For smaller applications it is really useful and it is faster than Hibernate.
As a last resort, rather put your SQL in a text file(s) which you open and execute.
How do you intend to create the webservice part? If you have the time to do, worth trying with Core Java or any Webservice framework, though I would suggest use Core java which would help to keep minimal dependency for your tool. Nevertheless, there is an ample amount of effort required to get the XML and Webservice requests in sync. My take - if it is not broken, dont fix it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This is my first question on StackOverflow. I'm new to it all. I know you're all pretty strict here, so I did all the research I could before asking this. Unfortunately I came up empty.
I'm building an app that shows an event that occurs every three months. This event has different shows in it that change very often. That is where my app comes in, it keeps people updated on what will be happening at the event. So when the event planners change their schedule, I need it to update my users. Pictures need to be changed too. Obviously, having them update the app is not the easiest way.
I know I could build a webpage, and have the app read off that. But I am really hoping there is an easier way than that. And if the webpage IS the only way, what is the best api?
So my question is; What is the easiest way to do this, so I can do more research about it?
https://www.parse.com/
Parse might be your best option if all you need is some basic data on a server. You don't need to write a whole web application or scrape html off of a web page. If you need other non technical users to write this data, you can make one "manager" version of your app and include some authentication logic (which you could also do against your Parse account). I have done this kind of thing using Amazon S3 buckets when I didn't have the time to write a whole web app just for some very basic server interaction for a mobile app.
You're going to want to have a server that your app can talk to. I would do this in two parts that have to happen more or less at the same pace. First, I would use Google's Cloud Messaging API to do the "light lifting" - it lets your app do a small check to see if anything needs updating. Then I would set up the server. You're obviously going to need to learn how to open up connections, downloads, storage, etc.
Important thing to keep in mind though, efficiency. Be smart about the data transimitted. Keeping it simple will benefit your app (less code, more straightforward) and your users (smaller app, less data usage).
But first, do research, try stuff out and don't be afraid to ask questions.
you don't need to build a webpage, you just need a server that the app can query
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the best way for replacing stored procedures in your database when you are moving to Hibernate. Imagine a java application that is working on its own without Hibernate, and then one will decide to use Hibernate. What is the best practice to do that? Shall I leave those parts using stored procedures intact and one by one get rid of the stored procedure and make it a stored procedure free program? or shall I HQL to call the stored procedure?
Look at it this way, isn't using stored procedure in contrast with using Hibernate? Isn't the purpose of using Hibernate to free coder from dealing with Relational mapping? If you have to deal with Stored procedures in your application, is it worth it to deal with Hibernate? If you have the knowledge and time to deal with Stored procedures, you better to use native sql rather than Hibernate?
Any ideas?
You could implement functionality similar to stored procedures using hibernates event system, http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/events.html
if its a good idea or not is a rather open ended question. I think, it depends on many different factors. Most importantly, what exactly are you building, what kind of team is working on it and how well is it documented.
Having things happen automatically, can be really neat, if its really well documented and if the developers actually pay attention to the documentation. Otherwise, it can lead to heaps of confusion. I suppose you have to ask the question, what is the benefits (if any) of using it, versus what the negatives are in your particular case. And make a decision based on that, I doubt very much you will find a right or wrong answer from what other people have experienced in the teams they have been working in, since it might not necessarily be appreciable for the project/team you are involved with.