I am using Spring MVC 3.2 Embedded database (H2) Support for storing real-time progress of tasks,queuing notifications and some temporary logs.The only problem with this approch is that my data gets vanished ; If the application redeploys or server restarts.This scenario is probably very rare in production environment but still I want to know that using embedded databases in production environment is a good choice or not?..Or is there any way to persist embedded database state to hard-disk so that the next time server boots we can restore the database state to stored checkpoint?
Thank you.
Embedded databases are not meant for use in a Production Environment. They are meant for a quicker development option as you do not need to have the dependency of an external database running. With an embedded database, you can programmatically fire it up and optionally initialize it based on your needs.
The reason your changes are being lost during redeployments is because you are using the in-memory version of HsQL instead of In-process(Standalone file) mode. You can use the Standalone mode which keeps the changes persistent.
In-Process (Standalone) Mode
This mode runs the database engine as part of your application program in the same Java Virtual Machine. For most applications this mode can be faster, as the data is not converted and sent over the network. The main drawback is that it is not possible by default to connect to the database from outside your application. As a result you cannot check the contents of the database with external tools such as Database Manager while your application is running. In 1.8.0, you can run a server instance in a thread from the same virtual machine as your application and provide external access to your in-process database.
The recommended way of using the in-process mode in an application is to use an HSQLDB Server instance for the database while developing the application and then switch to In-Process mode for deployment.
An In-Process Mode database is started from JDBC, with the database file path specified in the connection URL. For example, if the database name is testdb and its files are located in the same directory as where the command to run your application was issued, the following code is used for the connection:
Connection c = DriverManager.getConnection("jdbc:hsqldb:file:testdb", "sa", "");
The database file path format can be specified using forward slashes in Windows hosts as well as Linux hosts. So relative paths or paths that refer to the same directory on the same drive can be identical. For example if your database path in Linux is /opt/db/testdb and you create an identical directory structure on the C: drive of a Windows host, you can use the same URL in both Windows and Linux:
Connection c = DriverManager.getConnection("jdbc:hsqldb:file:/opt/db/testdb", "sa", "");
When using relative paths, these paths will be taken relative to the directory in which the shell command to start the Java Virtual Machine was executed. Refer to Javadoc for jdbcConnection for more details.
HSQL documentation
Related
We have single lower environment server where we publish all our applications for Developer testing, pre-business testing etc. Problem we are facing here is all the developers changing settings in the config file for their convenience.
For example, development application should point development SQL db, but they are changing it to QA. and in some cases instead of publishing the application to staging they are changing QA connection strings to staging because publishing to staging requires extra effort (Merging the code to Main branch etc). No matter how many times we send email to development group they keep doing the same thing.
Is there a way to control web.config/app.config edit permissions and limit it to one person based on the application?
If SQL Server Connection String is the problem, you can use cliconfg.exe to set a specific ALIAS, in this case you must configure the alias on each server in your environment (development, test and production), with this, the connection string will always be "Data Source = SRVDBAPP" on the web. config / app.config.
Internally each client SQL Server will redirect to the corresponding database.
I have hit a wall and can't figure out the heads from the tails. I am working with a team and we have developed an asp.net web application. There is a feature on the application that delivers directions from a database. The database is an MS Access database. I have published the application to an IIS7 Windows server. I also uploaded via FTP the Access database. We have tried all manner of connection string variants. We did not import the database in any way into Visual Studio but prefer to connect to where ever we decide to place it.
Now, I am wondering if using Access was a bad idea. Its a given that it was a rookie mistake since we are students working on our capstone project. Is there any other installs for the Access database that need to be installed on the server other than the driver for Access? Should my connection string be structured any other way that what it is presently? I will post the string below. Please note, I did not write this particular section of coding so if an error should be thrown it may be handled somewhere as to prevent the application from crashing on the user. Side note: Yes it does work fine on my local computer although the connection must be altered.
sConnection = #"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\inetpub\wwwroot\kioskApplication\www\Waypoints.accdb";
Thanks in advance for all the support and help with this issue.
Usually a WEB Application stores a file based database like MS-Access in its APP_DATA folder under the root of the site where every permission is granted to the IIS Service.
Then in your connection string you refer to this location using
Connection = #"Provider=Microsoft.ACE.OLEDB.12.0;
Data Source=|DataDirectory|\Waypoints.accdb";
See Where is DataDirectory
On the server side there is no need to install anything apart from the Microsoft Database Access Engine appropriate for the bitness of your web application. (32bit or 64bit)
i am creating a web application in asp.net with database on postgres. i have successfuly created a database backup by putting the destination of database backup on the webconfig file. the web application succesfully creates backups when published on windows server, however i was wondering if the server is changed to linux the destination folder would be invalid.what could be the solution for it to work on different OS??
another problem is that the postgres installation could be on any drive in linux whereas rightnow in my webapplication i open the system diagnostics to run the pgdump command using the info.filename="C:\Program Files\PostgreSQL\9.3\bin\" + commandType + ".exe ";
anyone has solution for multiOS database backup for postgres using asp.net?? is there any solution to this??
You can continue to use your backup scripts on Windows. pg_dump will happily connect to the remote database on the Linux box. E.g.
pg_dump -h my_linux_server ....
I strongly suggest reading the PostgreSQL docs on backup/restore. Consider setting up PITR in addition to periodic dumps. I'd recommend running PgBarman on the Linux server (archiving to an external drive, NAS, or network share) for point-in-time recovery, plus periodic dumps to the Linux box.
See: http://www.postgresql.org/docs/current/static/backup.html
I have an existing ASP.NET website that I would like to port to Azure within my free trial.
I would like the migration to be as painless as possible. The application uses log4net and NHibernate, plus it needs to share data with an application supposed to run on a virtual server.
Two questions can be asked as 1
How do I configure paths in Web.config to access a shared drive?
I need to configure the paths into which logs will be stored and, most important, I have to specify where the application will read the files written by the daemon that will run on my Azure Linux VM.
When both the app and the daemon ran on the same server (yes, I had Mono running fine) I just had to choose a shared local directory.
I'm not sure I'm totally understanding the scenario, but I'll try to give you a few options.
One - Windows Azure Web Sites (currently in Preview) could be a great option for your ASP.NET site. Of course, it depends what needs your site has. But, you can write your log4net files with web site and using NHibernate too.
Two - Web roles work great for situations like this. You would likely have to change some code to use blob storage for persistant file storage. You could use Windows Azure drives as a way to get a persistent location for log files. Windows Azure drives don't have a pre-determined drive letter, so you'd want to use the API to get to that. That may, or may not, be a good option for your situation. With web roles you could also write the log4net files to local storage and use Windows Azure diagnostics to transfer them periodically to blob storage. Just another way to persist the files.
Three - Using Windows Azure Virtual Machines (currently in Preview) you could write the log files to a data disk, which is backed by blob storage.
In the end, if you have files you need to share across instances and/or roles, then leveraging blob storage is likely your best option.
I built a prototype I'm looking to deploy. It uses a database file MySite.mdf that I created. At some point in the process, the database file ASPNETDB.mdf was added to the project.
When I look at the web.config file, I see the connectionStrings tag but in there I only see the nested tag for MySite.
Now that I'm looking to deploy, what do I put for the second file in the tag.
Thanks.
You are using a SQL Server Express User Instance; if the server you are deploying to support this, then you won't need to change your connection string when you deploy.
The most common problem deploying a user instance database is that the server doesn't support user instances. (Note that user instances are only supported by SQL Server Express Edition). If the server doesn't support this configuration, you'll have to create a database on the server and change your connection string, a process that could involve quite a few steps.
If, on the other hand, your server supports users instances and it's using the same SQL Instance name that you are, e.g. SQLEXPRESS, the default instance name, you should be able to simply deploy your site and it will run (as long as you include the ASPNETDB.mdf file in the deployment).