This sends a HEAD request to the registered URL for the webapp and
assumes that the app is dead if result is not 200.
This change caused a cascade of changes to the treatment of the
database table, because the DBMS layer insists that a table's primary
key be INTEGER. It was necessary to introduce a new column for the
purpose. This also means you can have more than one running instance
of the same UI, if you wish. But it also means that the sequence
required by the new column will overflow after about 2 billion starts.
The resolution to this problem is not to for DSpace to query all handles when assigning a new one (which can be taxing for large installs). Rather this fix changes the 'update-sequences.sql' scripts (for both Postgres & Oracle) such that the Handle sequence number will always be updated to ensure DSpace will assign a unique handle on the next handle request. I've also documented in the AIP backup/restore docs (DS-466) that update-sequence.sql script should always be run after a full AIP restore (which is the primary scenario where DSpace may encounter handle assignment issues).
git-svn-id: http://scm.dspace.org/svn/repo/dspace/trunk@5691 9c30dcfa-912a-0410-8fc2-9e0234be79fd
These seem to create the tables properly in Oracle 10g (based on my limited testing with a local Oracle install), and they also help fix DS-423 for Oracle.
git-svn-id: http://scm.dspace.org/svn/repo/dspace/trunk@4719 9c30dcfa-912a-0410-8fc2-9e0234be79fd
dspace/etc to overwrite the originals for the Oracle port to work.
The must be kept up to date with any schema changes!
git-svn-id: http://scm.dspace.org/svn/repo/trunk@1060 9c30dcfa-912a-0410-8fc2-9e0234be79fd
