After an extended period of intense software development, we are pleased to announce the release of Recital 10 which is a milestone in our development efforts.
The Recital 10 release notes can be found here.
- Recital
A powerful scripting language with an embedded database used for developing desktop database applications on Linux and Unix.
- Recital Server
A cross-platform SQL database and application server.
- Recital Web
A server-side scripting language with an embedded SQL database for creating web 2.0 web applications.
On exit of an .rsp page.
SAVE DATASESSION TO m_state
_SESSION["state"] = m_state
On entry to an .rsp page.
IF type( _session["state"] ) != "U"
m_state = _session["state"]
RESTORE DATASESSION FROM m_state
ENDIF
http://www.the-art-of-web.com/css/border-radius/
Recital is a proven and cost-effective database solution that will help reduce the cost of your database and application software infrastructure substantially. As an added benefit, Recital can run many legacy applications with little to no change as it understands FoxBASE, FoxPRO and Clipper languages as a subset of it's overall capability.
Occasionally as a Linux administrator you will be in the situation where working on a remote server and you are left with no option but to force a reboot the system. This may be for a number of reasons, but where I have found it most frequent is when working on Linux clusters in a remote location.
When the "reboot" or "shutdown" commands are executed daemons are gracefully stopped and storage volumes unmounted.
This is usually accomplished via scripts in the /etc/init.d directory which will wait for each daemon to shut down gracefully before proceeding on to the next one. This is where a situation can develop where your Linux server fails to shutdown cleanly leaving you unable to administer the system until it is inspected locally. This is obviously not ideal so the answer is to force a reboot on the system where you can guarantee that the system will power cycle and come back up. The method will not unmount file systems nor sync delayed disk writes, so use this at your own discretion.
To force the kernel to reboot the system we will be making use of the magic SysRq key.
The magic_SysRq_key provides a means to send low level instructions directly to the kernel via the /proc virtual file system.
To enable the use of the magic SysRq option type the following at the command prompt:
echo 1 > /proc/sys/kernel/sysrq
Then to reboot the machine simply enter the following:
echo b > /proc/sysrq-trigger
Voilà! Your system will instantly reboot.
{linkr:related;keywords:linux;limit:5;title:Related Articles}
{linkr:bookmarks;size:small;text:nn;separator:%20;badges:2,1,18,13,19,15,17,12}
There is a good article on the gluster website here which gives some good information regarding file system optimization suitable for a HA Recital cluster solution.
All temporary files created by Recital are stored in the directory specified by the environment variable DB_TMPDIR.
mkdir /opt/recital/tmp
mount -t tmpfs -o size=1g recitaltmpfs /usr/recital/tmp
Ext3 commits writes to disk within approximately 5 seconds - Ext4 can take from 40-150 seconds. In addition, if a system is using Ext3 and crashes before the commit takes place you will still have the previous contents of a file where under Ext4 the file will be empty. Theodore Tso feels that this is a failure at the application level and that the file system is behaving as designed and as specified by the POSIX spec (which apparently does not specify what is supposed to happen when a system is not shut down cleanly). His solution to the issue is to suggest proper use of fsync() and lists various scenarios/examples in post 54 of the bug report (linked above). In addition he wrote a patch that recognize the rename() situation mentioned in his post 54 yet retains the normal Ext4 behaviors and performance in the majority of cases. Also a more "proper" solution has been provided which allows the behavior of Ext3 to be retained under Ext4 by mounting it with alloc_on_commit.
A somewhat related topic is the use of on-board caching by hard drives. This behavior can be modified on most drives by using hdparm.
DB_SAMBA=YES ;export DB_SAMBA
preserve case = nodefault case = lowermangle case = yes
oplocks = False
share modes = no