User Login without DB, using Java.io (files)

[gekkokid]

Hi, i have been programming java for quite a while, but im doing my first java server-side project and wondered....


If i didnt use a db (such as MySql) to lookup user details but instead used seperate files for each user i.e. userfiles/g/gekkokid/useraccount.dat (the folders would be userfiles/_first_char_/_username_)

would there be a sigificant downside to it? say 5000 concurrent users

even if i used a database for the user login i would still have to open the files for the actual program to do its stuff.

any light on this issue would be appreciated thank you :)

[BigDog]

You would need to handle all the data store stuff then. J2EE comes with all kinds of DB access helpers and transaction support. Not using that stuff is sort of defeating the point of using a container. Plus, you would have to write code to handle concurrent access to the file, both reads and writes. I thnk it would be less work to use a DB.

At worse case you can use something like Derby (former Cloudscape). It is a real lightweight file based open source DB. It would be fine for a small app like this.

[gekkokid]

thanks for replying and the Derby idea, im looking into that right now but if i would use a db it would be MySQL only cos im familiar with that,

im no expert on servlet containers at all, but how would not using a db defeat the point of using a container?

all the servlet would do would be accessing a file which no other user/servlet would touch, ive already thought about the file locking,

[gekkokid]

with each login would the container have to reload the servlet each time cos it was accessing a different* file?

[BigDog]

You are falling into a trap a lot of new server side programmers make. While there is only ONE servlet instance, it handles MULTIPLE requests at the same time. Remember, more that one person can use a web page at a time - it is the whole point of delivering service in the manner. Thus a single servlet can access the same thing, more than once at the same time - two people just need to hit the same servlet at the same time, or a person just needs to hit the "reload" on their browser twice in a row - you now have concurrent access from the same servlet to the same file at the same time.

If two people (or more) hit the servlet at the same time, both of those requests will be handled AT THE SAME TIME. This is why you don't use class member items in servlets - you cannot expect them to retain their state. All of the data that is in reference to a particular request needs to be in the method, since all data in a method is threadsafe. But, if you have something refering to an outside actor (like a file), all those seperate requests will have access to it. Thus if you have a single, concrete item, like a file, it will get hit by two (or more) requests at the same time.

Because of the nature of server side programming, almost everything has a possibility of having concurrent access. If you really want to use a file, make sure that you synchronize the access methods to it. A singleton patttern is usually used for something like this. But If you get any real traffic this will bring the site to a standstill as they all wait for their access to the file. Also, you need to make sure that any other part of the program does not also access the file by itself - everything MUST use the class controlling access to the file, or else you will end up with concurrent access problems.

Depending on the container you use, it may or may not have the ability to abstract your data store. Tomcat does not have this. In this case you coudl look for a thrid party such as Hibernate. If you are using a full J2EE container (WebSphere, WebLogic, JBOSS), they can present as abstraction to the DB for you application. They handle connection pooling, IO, transactions, all the stuff.

Even using plain old JDBC is better than a file. Using JDBC at least the DB can deal with concurrency issues by itself.

[gekkokid]

thank you :)

[gekkokid]

BigDog thanks again for the info/advice :) i am going to use a java object db from http://www.db4o.com,