Source Allies Blog » Database

Hibernate Date vs Timestamp

David Kessler — Thu, 02 Feb 2012 20:24:21 +0000

I encountered a subtle hibernate mapping issue involving Dates and Timestamps. The following test recreates this issue.

package com.sourceallies.logging;
 
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
 
import java.sql.Timestamp;
import java.util.Calendar;
import java.util.Date;
import java.util.List;
 
import javax.annotation.Resource;
 
import org.apache.commons.lang.time.DateUtils;
import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.classic.Session;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.transaction.TransactionConfiguration;
import org.springframework.transaction.annotation.Transactional;
 
import com.sourceallies.Person;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@TransactionConfiguration(defaultRollback=false)
public class HibernateDateTimeTest {
 
	@Resource
	private SessionFactory sessionFactory;
 
	private Session currentSession;
 
	private Date birthDateWithTime;
	private Date birthDateWithoutTime;
	private Date createDate;
	private Date modifyDate;
 
	@Before
	public void setUp() throws Exception{
		currentSession = sessionFactory.getCurrentSession();
		birthDateWithTime = new Date();
		birthDateWithoutTime = DateUtils.truncate(birthDateWithTime, Calendar.DATE);
		createDate = new Date();
		modifyDate = new Date();
	}
 
	@Test
	@Transactional
	public void testSave(){
		Person person = new Person("testFirst", "testLast", 
                      birthDateWithTime, createDate, modifyDate);
 
		assertFalse(person.getBirthDate() instanceof Timestamp);
		assertFalse(person.getCreateDate() instanceof Timestamp);
		assertFalse(person.getModifyDate() instanceof Timestamp);
 
		saveOrUpdate(person);
	}
 
	@Test
	@Transactional
	public void testFind(){
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
		Person foundPerson = people.get(0);
 
		assertTrue(foundPerson.getBirthDate() instanceof Date);
		assertTrue(foundPerson.getCreateDate() instanceof Timestamp);
		assertTrue(foundPerson.getModifyDate() instanceof Timestamp);
 
		assertFalse(foundPerson.getBirthDate().equals(birthDateWithTime));
		assertTrue(foundPerson.getBirthDate().equals(birthDateWithoutTime));
		assertFalse(foundPerson.getCreateDate().equals(createDate));
		assertFalse(foundPerson.getModifyDate().equals(modifyDate));
	}
 
	public void saveOrUpdate(Person person) {
		currentSession.saveOrUpdate(person);
		currentSession.flush();
	}
 
	@SuppressWarnings("unchecked")
	private List<Person> findAll() {
		Criteria criteria = currentSession.createCriteria(Person.class);
		List<Person> people = criteria.list();
		return people;
	}
}

Here is the mapping for person.

...
@Entity
public class Person {
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	private Long id = -1L;
 
	@Column
	private String firstName;
 
	@Column
	private String lastName;
 
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	@Type(type="timestamp")
	private Date createDate;
 
	@Column
	private Date modifyDate;
	...
}

There are three Date fields: ‘birthdate’, ‘createDate’, and ‘modifyDate’. The fields ‘birthDate’ and ‘createDate’ have a specified Type. The field ‘modifyDate’ however, does not have a specified Type. The generated SQL from Hibernate is as follows.

CREATE TABLE Person (id bigint generated BY DEFAULT AS identity (start WITH 1), 
birthDate date, createDate timestamp, firstName varchar(255), 
lastName varchar(255), modifyDate timestamp, PRIMARY KEY (id))

We see that Hibernate created ‘birthDate’ as a ‘Date’ and the other two were created as a ‘Timestamp’. The primary difference between ‘Date’ and ‘Timestamp’ in SQL is that ‘Timestamp’ holds the date and time while the ‘Date’ only holds the date.

At first glance this is not a big deal, but let’s take a closer look at the test.

 
	@Test
	@Transactional
	public void testSave(){
		Person person = new Person("testFirst", "testLast", 
                           birthDateWithTime, createDate, modifyDate);
 
		assertFalse(person.getBirthDate() instanceof Timestamp);
		assertFalse(person.getCreateDate() instanceof Timestamp);
		assertFalse(person.getModifyDate() instanceof Timestamp);
 
		saveOrUpdate(person);
	}

Person is created with three Dates that all include date and time values.

	@Test
	@Transactional
	public void testFind(){
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
		Person foundPerson = people.get(0);
 
		assertTrue(foundPerson.getBirthDate() instanceof Date);
		assertTrue(foundPerson.getCreateDate() instanceof Timestamp);
		assertTrue(foundPerson.getModifyDate() instanceof Timestamp);
 
		assertFalse(foundPerson.getBirthDate().equals(birthDateWithTime));
		assertTrue(foundPerson.getBirthDate().equals(birthDateWithoutTime));
		assertFalse(foundPerson.getCreateDate().equals(createDate));
		assertFalse(foundPerson.getModifyDate().equals(modifyDate));
	}

When Hibernate retrieves a Person from the database the ‘createDate’ and ‘modifyDate’ have been converted to Timestamps. At first glance this doesn’t appear to be a big deal. java.sql.Timestamp extends java.util.Date. But why are they not equal. I found a helpful answer to this question in Effective Java (2nd Edition) page 41.

There are some classes in the Java platform libraries that do extend an instantiable
class and add a value component. For example, java.sql.Timestamp
extends java.util.Date and adds a nanoseconds field. The equals implementation
for Timestamp does violate symmetry and can cause erratic behavior if
Timestamp and Date objects are used in the same collection or are otherwise intermixed.
The Timestamp class has a disclaimer cautioning programmers against
mixing dates and timestamps. While you won’t get into trouble as long as you
keep them separate, there’s nothing to prevent you from mixing them, and the
resulting errors can be hard to debug. This behavior of the Timestamp class was a
mistake and should not be emulated. (Bloch, Effective Java, 2nd Ed.)

If you want to read more about ‘equals’ read chapter 3, Item 8 in Effective Java (2nd Edition). Apart from a hack there are two primary ways to solve this issue. The first way involves typing ‘createDate’ and ‘modifyDate’ to Timestamp.

	...
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	private Timestamp createDate;
 
	@Column
	private Timestamp modifyDate;
        ...

The second approach uses a custom UserType. Here is a custom UserType that converts Timestamp to Date and vise versa. There is a side effect with this solution. Converting Timestamp to Date drops the nanosecond precision. If this is not acceptable then the previous solution should be used.

package com.sourceallies;
 
import java.io.Serializable;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Timestamp;
import java.sql.Types;
import java.util.Date;
 
import org.hibernate.HibernateException;
import org.hibernate.usertype.UserType;
 
public class DateTimeUserType  implements UserType {
 
	@Override
	public int[] sqlTypes() {
		 return new int[]{Types.TIMESTAMP};
	}
 
	@SuppressWarnings("rawtypes")
	@Override
	public Class returnedClass() {
		return Date.class;
	}
 
	@Override
	public boolean equals(Object x, Object y) throws HibernateException {
		 return x == y || !(x == null || y == null) && x.equals(y);
	}
 
	@Override
	public int hashCode(Object x) throws HibernateException {
		return x.hashCode();
	}
 
	@Override
	public Object nullSafeGet(ResultSet rs, String[] names, Object owner)
			throws HibernateException, SQLException {
		Timestamp timestamp = rs.getTimestamp(names[0]);
        if (rs.wasNull()) {
            return null;
        }
        return new Date(timestamp.getTime());
	}
 
	@Override
	public void nullSafeSet(PreparedStatement st, Object value, int index)
			throws HibernateException, SQLException {
        if (value == null) {
            st.setNull(index, Types.TIMESTAMP);
        }
        else {
            Date date = (Date) value;
            Timestamp timestamp = new Timestamp(date.getTime());
            st.setTimestamp(index, timestamp);
        }
	}
 
	@Override
	public Object deepCopy(Object value) throws HibernateException {
		return value;
	}
 
	@Override
	public boolean isMutable() {
		return false;
	}
 
	@Override
	public Serializable disassemble(Object value) throws HibernateException {
		 return (Serializable) value;
	}
 
	@Override
	public Object assemble(Serializable cached, Object owner)
			throws HibernateException {
		return cached;
	}
 
	@Override
	public Object replace(Object original, Object target, Object owner)
			throws HibernateException {
		return original;
	}
}

Here is the way to use it in the Person class.

@Entity
@TypeDefs({
		@TypeDef(name="dateTimeUserType", typeClass=DateTimeUserType.class)
})
public class Person {
	...
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	@Type(type="dateTimeUserType")
	private Date createDate;
 
	@Column
	@Type(type="dateTimeUserType")
	private Date modifyDate;
        ...

Either of these solutions will prevent the ‘equals’ issue that we encountered before. This issue is not a Hibernate issue it is truly a Java issue as is stated in Effective Java (2nd Edition). Hibernate can be challenging enough without these subtle issues that are easy to miss until a bug is reported.

Here is the complete code. Hibernate Logging Zip .

Incrementing Oracle Sequences Without Permissions

Tim Bierbaum — Fri, 23 Apr 2010 19:06:52 +0000

If you are ever working with a database where data is consistently being imported, dropped, and/or restored; sooner or later you will find yourself in the situation where the primary key of a table is no longer synchronized with the sequence used to generate it.

If you have the appropriate permissions, this is easy to fix. Say you need to advance the sequence by 500, you just execute the following sql:

ALTER sequence MY_SEQ increment BY 500;
SELECT MY_SEQ.NEXTVAL FROM dual;
ALTER sequence MY_SEQ increment BY 1;

What do you do if you don’t have the correct permissions to do this? You can always call up the dba and ask him. If you’re impatient, you can also do a little pl/sql programming to accomplish the same thing. All you want to do is just repeatedly select the next value until the sequence value is higher that the current key value.

DECLARE
  current_value NUMBER;
  seq_val NUMBER;
BEGIN
  SELECT MAX(MY_TABLE.id) INTO current_val FROM MY_TABLE;
  WHILE current_val >= seq_val
  LOOP
    SELECT MY_SEQ.NEXTVAL INTO seq_val FROM dual;
  END LOOP;
END;

Of course, if you encounter this situation once, chances are that you will encounter it many times. Next, you can create a function that takes the table name, key column name, and sequence name and then executes dynamically created sql to fix the problem.

CREATE OR REPLACE PROCEDURE INCREMENT_SEQ(IN TABLE_NAME, IN ID_COLUMN_NAME, IN SEQUENCE_NAME) IS
DECLARE
  current_value NUMBER;
  seq_val NUMBER := -1;
BEGIN
  EXECUTE IMMEDIATE 'select max(' || TABLE_NAME || '.' || ID_COLUMN_NAME || ') into current value from ' || TABLE_NAME;
  WHILE current_val >= seq_val
  LOOP
    EXECUTE IMMEDIATE 'select ' || SEQUENCE_NAME || ".nextval into seq_val from dual';
  end loop;
END INCREMENT_SEQ;

Now, you should be able to fix any sequence/key mismatches simply by calling the procedure.

INCREMENT_SEQ('MY_TABLE', 'ID', 'MY_SEQ');

MySQL Master/Slave configuration with EJB3 and JPA

Vaithi Subramanian — Fri, 26 Mar 2010 18:33:19 +0000

Well this turned out to be quite an exercise.

The goal: scalable reads with MySQL in master-slave configuration, writing to the master, and reading from N slaves, load balanced in round-robin fashion (or something).

The problem: using JPA (Java Persistence API) instead of direct JDBC calls. Turns out the MySQL ReplicationDriver (used to load balance reads to slaves and send writes to the master) relies on the readOnly state of the Connection in order to decide whether it’s a read or a write. With direct JDBC calls, I could get the Connection and toggle the readOnly state as needed.

However, buried under JPA and EntityManager and so on, there’s no way to do that. So I looked into other solutions (LBPool, for instance), but nothing out there seems to be intended for JPA environment.

So I had to do it myself… in digging around in the MySQL Connector/J source, I discovered the loadbalance option, intended for use w/ MySQL Cluster, because in that environment, you don’t need to distinguish between master and slave, they’re all just nodes.

The loadbalance option wouldn’t work directly for me, of course, because I don’t want to load balance writes, just reads.

Soulution to the problem is to use two data sources, one for reads, and the other for writes, I can stick the read data source behind all my “fetch stuff” APIs, and use the write data source for everything else. Then I can use the loadbalance option for the read data source, because I know for certain I’m never sending it any writes.

I am currently using Jboss 4.2.1 GA here my mysql-ds.xml

>
  >
    >MasterA>
    >jdbc:mysql://masterDB/databasename>
    >com.mysql.jdbc.ReplicationDriver>
    >username>
    >password>
    >10>
    
    >50>
    >10>
    >com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter>
    >com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker>
    
    >
      >mySQL>
    >
  >
  >
    >SlaveA>
    >jdbc:mysql://slaveA,slaveB/databasename>
    >com.mysql.jdbc.ReplicationDriver>
    >username>
    >password>
    >10>
    
    >50>
    >10>
    >com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter>
    >com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker>
    
    >
      >mySQL>
    >
  >
>

Persistence.xml for the JTA datasources.

 version="1.0" encoding="UTF-8"?>
			 version="1.0"
	xmlns="http://java.sun.com/xml/ns/persistence"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence persistence_1_0.xsd">
 name="Master">
	>org.hibernate.ejb.HibernatePersistence>
	>
		java:/MasterA
	>
	>
		 name="hibernate.dialect" value="org.hibernate.dialect.MySQL5Dialect" />			
		 name="hibernate.connection.readOnly" value="true" /> 	>
>
 name="Slave">
	>org.hibernate.ejb.HibernatePersistence>
	>
		java:/SlaveA
	>
	>
		 name="hibernate.dialect" value="org.hibernate.dialect.MySQL5Dialect" />			
		 name="hibernate.connection.readOnly" value="true" /> 	
>
>
>

For normal JDBC connections read only state can changed like the following code.

public static void main(String[] args) throws Exception {
    ReplicationDriver driver = new ReplicationDriver();
 
    Properties props = new Properties();
 
    // We want this for failover on the slaves
    props.put("autoReconnect", "true");
 
    // We want to load balance between the slaves
    props.put("roundRobinLoadBalance", "true");
 
    props.put("user", "user");
    props.put("password", "password");
 
    //
    // Looks like a normal MySQL JDBC url, with a
    // comma-separated list of hosts, the first
    // being the 'master', the rest being any number
    // of slaves that the driver will load balance against
    //
 
    Connection conn =
        driver.connect("jdbc:mysql:replication://master,slave1,slave2,slave3/databasename",
            props);
 
    //
    // Perform read/write work on the master
    // by setting the read-only flag to "false"
    //
 
    conn.setReadOnly(false);
    conn.setAutoCommit(false);
    conn.createStatement().executeUpdate("UPDATE some_table ....");
    conn.commit();
 
    //
    // Now, do a query from a slave, the driver automatically picks one
    // from the list
    //
 
    conn.setReadOnly(true);
 
    ResultSet rs =
      conn.createStatement().executeQuery("SELECT a,b FROM alt_table");
 
     .......
  }

Conculsion:
Thus with the help of two data sources I am able to replicate the functionality of Master/Slave Read scalability. If you are using the normal JDBC connection then changing the read-only is as simple as the above code. Hope this will be helpful for someone who needs to setup Replication in the code level.

IP Addresses in PHP/MySQL

Mark Ciecior — Fri, 12 Feb 2010 13:32:39 +0000

I’ve been working on a web-based tool that stores, among other network-related things, IP addresses. When I first started I stored each IP address as four TINYINTS (0-255 for each octet):

mysql> DESC ipaddresses;
+----------+---------------------+------+-----+---------+----------------+
| FIELD    | Type                | NULL | KEY | DEFAULT | Extra          |
+----------+---------------------+------+-----+---------+----------------+
| id       | int(10) UNSIGNED    | NO   | PRI | NULL    | AUTO_INCREMENT | 
| A        | tinyint(3) UNSIGNED | NO   |     | NULL    |                | 
| B        | tinyint(3) UNSIGNED | NO   |     | NULL    |                | 
| C        | tinyint(3) UNSIGNED | NO   |     | NULL    |                | 
| D        | tinyint(3) UNSIGNED | NO   |     | NULL    |                | 
+----------+---------------------+------+-----+---------+----------------+
5 rows IN SET (0.00 sec)
 
mysql> SELECT * FROM ipaddresses WHERE id=1
+----+----+----+----+-----+
| id | A  | B  | C  | D   |
+----+----+----+----+-----+
|  1 | 10 | 20 | 30 | 131 |
+----+----+----+----+-----+
1 row IN SET (0.02 sec)

As I started manipulating these addresses I found it awkward to do common binary math (like bitwise ANDs). I decided instead to store these 32-bit values as unsigned integers (of length 32). To make my life easier yet, MySQL and PHP both have native functions to convert IP addresses between my old and new formats to make this migration extremely easy.

In MySQL:

mysql> SELECT INET_ATON('10.20.30.131');
+---------------------------+
| INET_ATON('10.20.30.131') |
+---------------------------+
|                 169090691 | 
+---------------------------+
1 row IN SET (0.00 sec)
 
mysql> SELECT INET_NTOA(169090691);
+----------------------+
| INET_NTOA(169090691) |
+----------------------+
| 10.20.30.131         | 
+----------------------+
1 row IN SET (0.00 sec)

In PHP:

$ip_string="10.20.30.131";
$ip_integer = ip2long($ipstring);
echo $ip_integer; ## 169090691
echo long2ip($ip_integer); ## 10.20.30.131

In another example of inefficiency, I used to gather all sorts of info from the user and use PHP to make multiple SQL queries before modifying my data. I’ve since learned about stored procedures – the database does all the work and I only need to make one SQL call from PHP. This presented me with an unexpected problem, however:

mysql> CALL getAddress();
+----+----+----+----+----+
| id | A  | B  | C  | D  |
+----+----+----+----+----+
|  1 | 10 | 20 | 30 | 131|
+----+----+----+----+----+
1 row IN SET (0.00 sec)
 
Query OK, 0 rows affected (0.00 sec)

The string “Query OK, 0 rows affected (0.00 sec)” is a second result set, which the PHP mysql library can’t handle. The fix here is to use the mysqli library instead and access only the result sets you need. In my case I’m only concerned with the first result set so I added a bunch of wasteful while loops after each of my CALL queries.

while (mysqli_next_result()){}

Lastly, PHP’s ip2long function treats 32-bit numbers as signed ints, so I had to specifically treat them as unsigned ints:

echo $ip_integer; ## BAD
echo sprintf(%u, $ip_integer); ## GOOD

Building Multi-Criteria Search Queries in Hibernate

Vaithi Subramanian — Wed, 09 Dec 2009 18:02:53 +0000

In this post I am going to show how to write queries multi-criteria search screens. There are two approaches for making this possible.

HQL for building the Query
Building Query using Criteria API

HQL for building the Query

Here I am going to show 2 approaches to building the HQL and try to point out the better approach.

Approach I:String concatenation
This approach uses String concatenation and setting up the values directly in the query.

if (startDate != null) {
   if (firstClause) {
      query = query + " where ";
   }
   else {
      query = query + " and ";
   }
 
   query += " s.date >= '" + startDate + "'";
}

Using the above approach there might be a chance of SQL Injection attack and using string concatenation is inherently error-prone.

Approach 2: Criteria as Named Parameters

In this one we create two map to hold parameter name and value which could be binded to the HQL during the execution.

Here is brief example of the approach.

public List search() {
   StringBuilder aQuery = 
      new StringBuilder(" from document p where p.id is not null ");
   HashMap parameterMap = new HashMap();
   HashMap parameterListMap =  new HashMap();
 
   //Collection Criteria
   if (countyList != null) {
      buildCollectionCriterion(aQuery, parameterListMap, "listID", countyList);
   }
 
   //Date Criteria
   if (startDate!= null || endDate != null) {
      buildDateCriterion(aQuery, parameterMap, "dateField",startDate, endDate);
   }
 
   Query query = hibSession.createQuery(aQuery.toString());
 
   for (String key : parameterMap.keySet()) {
      query.setParameter(key, parameterMap.get(key));
   }
 
   for (String key : parameterListMap.keySet()) {
      query.setParameterList(key, parameterListMap.get(key));
   }
 
   List results = query.list();
}
 
//Helper Methods for different type of criteria
 
protected void buildCollectionCriterion(StringBuilder aQuery, 
                                        Map parameterListMap, 
                                        String aFieldName, 
                                        Collection aList) {
   if (aList != null && !aList.isEmpty()) {
      aQuery
         .append(" and p.")
         .append(aFieldName)
         .append(" in (:")
         .append(aFieldName)
         .append(")");
      parameterListMap.put(aFieldName, aList);
   }
}
 
public void buildDateCriterion(StringBuilder aQuery, 
                               Map parameterMap, 
                               String aFieldName, 
                               Date aStartDate, 
                               Date anEndDate) {
   if (aStartDate != null && anEndDate != null) {
      aQuery
         .append(" and ( p."
         .append(aFieldName)
         .append(" between :aStartDate and :anEndDate)");
      parameterMap.put("aStartDate", aStartDate);
      parameterMap.put("anEndDate", anEndDate);
   }
   else if (aStartDate != null) {
      aQuery
         .append(" and  (p.")
         .append(aFieldName)
         .append(" >= :aStartDate)");
      parameterMap.put("aStartDate", aStartDate);
   } 
   else if (anEndDate != null) {
      aQuery
         .append(" and (p.")
         .append(aFieldName)
         .append(" <=:anEndDate");
      parameterMap.put("anEndDate", anEndDate);
   }
}

Building Query using Criteria API

public List search() {
        Criteria c = hibSession.createCriteria(Document.class);
        c.add(Restrictions.notNull("id"));
 
        if(countryList != null) {
                c.add(Restrictions.in("listId", countryList));
        }
 
        if(startDate != null) {
                c.add(Restrictions.ge("dateField", startDate);
        }
 
        if(endDate != null) {
                c.add(Restrictions.le("dateField", endDate);
        }
 
        return c.list();
}

Conclusion

The Hibernate Criteria API is a powerful and elegant library which is well adapted for implementing multi-criteria search functionality and also HQL queries must be built ‘on-the-fly’. Using it in appropriate circumstances will result in cleaner, clearer, more reliable and more maintainable code.

PL/SQL Variables and Connection Pooling

Tim Bierbaum — Wed, 11 Nov 2009 16:56:44 +0000

I recently had to implement a common feature across multiple applications and app servers, all of which point to the same Oracle database. For reasons unrelated, I chose to implement this feature using PL/SQL. You can all stop laughing now. I ended up with something resembling:

CREATE OR REPLACE PACKAGE BODY MY_PKG IS
   g_enabled BOOLEAN := TRUE;
 
   PROCEDURE enable_sp() IS
      BEGIN
         g_enabled := TRUE;
      END;
 
   PROCEDURE disable_sp() IS
      BEGIN
         g_enabled := FALSE;
      END;
 
   FUNCTION is_enabled_fn() IS
      l_return_value NUMBER;
 
      BEGIN
         IF g_enabled THEN
            l_return_value := 1;
         ELSE
            l_return_value := 0;
         END IF;
 
         RETURN l_return_value;
      END;
END MY_PKG;

Seems pretty innocent, doesn’t it?

So, I write unit tests in java to test everything. It all seems to be working. It goes through code review. Nothing more serious than cosmetic issues were found. It goes through the qa cycles. It all seems to be working. It gets deployed to production. At first, it seems to be working. Then I start to see some interesting behavior.

Lesson #1:

PL/SQL data types aren’t as straight forward as I would have liked. The variable g_enabled is of type BOOLEAN. This is a data type built into PL/SQL. It is not a data type in Oracle’s version of SQL. Why is this significant? Consider the two following scenario’s and their result (assuming that is_enabled=TRUE) -

BEGIN
 
  DBMS_OUTPUT.put_line(my_pkg.is_enabled_fn());
 
END;

This will print out a 1 to the standard output.

SELECT my_pkg.is_enabled_fn() FROM dual;

This query will return 0.

This was not what I expected. I would have expected the second query to return a 1. The reason it doesn’t, is that the query is not run in a PL/SQL block. This results in the BOOLEAN data type to not be defined and the if statement in is_enabled_fn() to always evaluate to false.

Lesson #2:

Package variables are connection private. I create two connections, A and B, to the database. If I call disable_sp() in connection A, is_enabled_fn() will still return a 1 in connection B. The value of the variable is not shared across the connections. If I were then to create a connection C, is_enabled_fn() will return 0. This is because connection C was created after the value was set in connection A. While it wasn’t what I initially expected, it makes some sense in that the connections don’t share memory. The really big problem comes into play when app servers pool connections and might not close them for weeks at a time.