Lock Manager

Integrating COBRA objects with Java Server Pages is a breeze. COBRA objects

already support the Java Beans pattern of getter and setter methods. The

following example (JSP 1.0) shows an HTML form and a login bean (that is also

a COBRA persistent object).

First we have to specify which bean we want to use:

<%@ page import="uk.co.kimble.jams.Account" %>

<jsp:useBean id="loginBean" class="uk.co.kimble.examples.Account"

scope="session"/>

<jsp:setProperty name="loginBean" property="*"/>

The COBRA object is called Account, the JSP engine creates an instance of

account called loginBean that exists for the session, alternative scopes are page

and application.

<%

// take user straight to admin page if they are logged in

if (loginBean.logged_in) {

pageContext.forward("next.jsp10");

}

%>

If the user is already logged in, then the form is skipped and the user is

forwarded to the next page. Otherwise the user is prompted to enter a

username and password. To save the user re-typing unnecessary data the

username value is extracted from the bean. We may even have saved this value

on the user’s browser using a cookie so that it is there at the start of a new

session.

<FORM name="login">

<TABLE>

<TD><INPUT name=username TYPE=text value=

"<%= loginBean.getUsername() %>"

</TD>

</TR>

<TR>

<TD><INPUT TYPE=password name=password value="" >

</TD>

</TR>

<TR>

<TD><INPUT TYPE=submit name=connect value="Enter">

</TD>

</TR>

</TABLE>

</FORM>

<%= loginBean.getReply() %>

The account bean has two variables corresponding to the column names in the

account table: username and password. There are setters and getters for these

values as well as a getReply() method and a setConnect() method. These

methods are ignored by COBRA because they do not correspond to columns in

the class_dictionary.

On the first run through the form username is set to blank and the reply text

"click enter to log in to server" is displayed at the bottom of the form.

When the form is submitted tce data is sent to the server via the URL query

string (as specified by the default GET method). Where the form data names

correspond to the included bean method names each settor is called in turn.

That is the username is set to the entered username value, the password is set

to the entered password value and the setConnect() method is called with the

String parameter "Enter".

package uk.co.kimble.examples;

import uk.co.kimble.cobra.rmi.*;

import java.rmi.Naming;

public class Account extends PersistentObject {

String username = "";

String password;

public boolean logged_in = false;

public String reply;

public Account() {

super();

init();

}

void init () { reply = "Click enter to login to server"; }

public String getPassword() { return password; }

public void setPassword(String s) { password = s; }

public String getUsername() { return username; }

public void setUsername(String s) { username = s; }

public String getReply() { return reply; }

public void setConnect(String s) {

try {

PersistentObjectFactory rof = (PersistentObjectFactory)

Naming.lookup("//monte-carlo/JamsServer");

PersistentSource pos = rof.getPersistentSource();

Account a = (Account) pos.retrieve(this);

if (a.getPassword().equals(password) {

logged_in = true;

} else {

reply = "Incorrect username or password<br>";

}

} catch (Exception e) {

reply = "Could not log in, please check your username and

password<br><i>" + e.toString() +"</i><br>";

logged_in = false;

}

}

}

The setConnect() method connects to the COBRA server using RMI (yes this is a

3 or 4 tier application depending on how you look at things). The user account

corresponding to the submitted username is retrieved and the passwords

compared. If there is a match logged_in is set to true (so when we drop through

the form again we are taken to the new page) otherwise the reply message is

changed to warn the user of the error.

In practise we wouldn’t want to do the RMI lookup every time we action the

bean so this would be shifted off somewhere else, probably to another bean with

session scope.

JDBC offers the possibility of pre-compiling frequently used statements for

efficiency. This has direct application to the object persistence mechanism

where the statements to retrieve, update, create and delete a class will be

constant for all instantiations of the object, only the data will change.

TBD

An example lock manager using Object Ids is included in

Local Test Machine: AMD K5/133 running Redhat Linux 5.1, Postgres 6.3.4,

JDK 1.1.5

Remote Test Machine: AMD K6/180 running Windows NT 4.0 sp 3, Symantech

2.5 JIT

Network: 10 Mbps Ethernet

In this test RMI is used over the TCP/IP loopback interface. Connection to the

database over the same interface.

PersistentObject.Retrieve : 50 ms

PersistentObject.retrieveSet: 100 ms

PersistentObject setter/getter: 5 ms

PersistentObject.nextObject: 45 ms

Overall Retrieve Time 70ms

RMI is used over a 10 Mbps LAN. The remote machine runs the COBRA

middle-tier but connects back to the local machine where the database is

stored. Getter/Setter/nextObject speed is better because the operation is

divided amongst two processors and network latency is not significant. The

retrieves take longer as a connection is made back to the database on the local

machine.

PersistentObject.Retrieve : 341 ms

PersistentObject.retrieveSet: 365 ms

PersistentObject setter/getter: 3 ms

PersistentObject.nextObject: 20 ms

Overall Retrieve Time 398 ms

PersistentObject.Retrieve : 80 ms

PersistentObject.retrieveSet: 91 ms

PersistentObject setter/getter: 0 ms

PersistentObject.nextObject: 5 ms

The remote interface was now modified so that rather than getting a reference

to a remote object on the server a local object was created, its primary keys set

and then it was sent over the network, an initialised object was then returned

to the user. The overall time is about the same as with the remote object case.

PersistentObject.Retrieve : -

PersistentObject.retrieveSet: -

PersistentObject setter/getter: 0 ms

PersistentObject.nextObject: -

Overall Retrieve Time 73 ms

PersistentObject.Retrieve : -

PersistentObject.retrieveSet: -

PersistentObject setter/getter: 0 ms

PersistentObject.nextObject: -

Overall Retrive Time 412 ms