Anyone determined to send fake score data can do so, and there's really nothing you can do about it other than move all your game logic server-side. Even then someone could automate the game with a bot, though that's a harder problem, most people won't bother with it, and you should take it as a good sign of popularity if they do.
That's true. Well, I will be monitoring the table anyways. I will manually delete fake record if I see any suspicious.
I have never used SQLite, so I just read about it. http://www.sqlite.org/whentouse.html
The only possible issue I found would be the concurrency. It says that the database locks reading/writing when one is in process. Though it says the lock would last for a few dozen milliseconds at most usually. I guess I shouldn't consider this as an issue for this case since there won't be that many people.
All I need is fetch, insert, and delete of a record. So I think I should consider SQLite as my solution, now.
But I do want to add some kind of protection in the code at least protecting from modifying the score board by just passing scores through url.
Some anecdotal experience...
The company I work (Coverity) for uses and used SQLite quite extensively with our product over the course of the last 8 years. It does not scale well and seems susceptible to both corruption and concurrency issues.
 While I don't know if it's any better in this regard, I would recommend either derby or hsqldb as they're easy to setup, work well with Java, and will get around your original blocker.
 I noticed that sproingle already recommended the above...