When you choose the database for repository you should base your decision on the same criteria like choose the database for web application. For instance, respond yourself to question: if derby is good for jackrabbit, why not use derby as a database for web application.
From this point of view I recommend to use the same database for both. This also give you advantages for maintenance, you will need to know only one database and don't need to duplicate maintenance scripts.
I suggest to use a database with table spaces. Data for web application and attachment to be store in different table spaces for optimization. Even you can have one database for both web application and jackrabbit with different schema and table spaces. More you can use the same database connection of JEE container.
Do you need one commit for both (web application and jackrabbit) known as 2 phase commit? If yes I know spring can do it, but I can't help you with that because I didn't work with spring.
When dealing with a web application there are two components of primary interest - the server and the network.
A java web application runs in an application server (this is an application such as jBoss, Weblogic, or self contained jetty) on a server itself (linux, windows, etc...).
If the application server is not running, the applications within it are not running and you will not be able to connect to them. This is true no matter if the applications within them are providing web services or more traditional web pages.
If the server itself is down, the applications running on the server (the application server, database and the like) are not running.
If the network between you and the server is down then, well, the network is down and you cannot connect to the applications (no matter if they are running or not).
The standard approach to dealing with the server is down is redundancy - putting the application on multiple servers so that if one fails to connect it will attempt to connect to another one. This does not guarantee that it will always work (a network outage in a wide enough area or a cascading problem in cloud computing can take multiple systems off line).
The specifics of how much and what redundancy are necessary depends on a given application's requirements. Some people need 99.999% uptime, some just need 99% uptime (and wait for the network or the system to correct itself rather than investing in additional redundancy).
Remember that when planning for redundancy it is likely necessary that multiple components will need to be redundant. If one has multiple redundant web applications all using the same database, and the database goes down you still have a single point of failure with the database.
Ok, so lets say the network has gone down after you have loaded the page. You are now offline.
Html 5 provides the possibility for having some amount of local processing. Note that this means that you can only work with the code and data that you have on the machine. If the business logic for the application is hosted on the cloud it would mean that when the cloud is unavailable, that portion of logic is unavailable.
Some resources for html 5 offline applications:
A google search for "html5 offline web apps" (and related queries) will provide more resources.
Best Answer
Before going web or standalone, figure out your business domain.
pros and cons of making these two application...
There can be a huge list, but here are just few points for standalone:
pros:
cons: