Hi All,

When testing the following with a light load I have no problems, however as the load increases things go bad very fast. My question is how can I do is its thread safe - should I be looking at optimistic locking to help me here ? I use JSP purely to test normally accessing via apache axis as a webservice. My user.hbm.xml is as simple as it gets and unsaved-value="null is set.

net.sf.hibernate.HibernateException: SQL insert, update or delete failed (row not found)
at net.sf.hibernate.impl.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:25)
at net.sf.hibernate.persister.EntityPersister.delete(EntityPersister.java:599)
at net.sf.hibernate.impl.ScheduledDeletion.execute(ScheduledDeletion.java:29)
at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2418)
at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2376)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2240)
at com.playingwithmatches.xeg.persistence.UserDAO.removeUser(UserDAO.java:88)

or

2004-09-28 08:15:58,881 ERROR net.sf.hibernate.impl.SessionImpl - Could not synchronize database state with session
net.sf.hibernate.JDBCException: could not insert: [com.playingwithmatches.xeg.webservices.User#393232]
at net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:478)
at net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:442)
at net.sf.hibernate.impl.ScheduledInsertion.execute(ScheduledInsertion.java:29)
at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2418)
at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2371)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2240)
at com.playingwithmatches.xeg.persistence.UserDAO.saveUser(UserDAO.java:41)



<hibernate-mapping>
<class name="com.playingwithmatches.xeg.webservices.User" table="users">

<id name="userid" column="userid" type="java.lang.Long" unsaved-value="null">
<generator class="hilo"/>
</id>

<property name="firstname" column="firstname" type="string" length="12" not-null="true"/>
<property name="lastname" column="lastname" type="string" length="15" not-null="true"/>

<property name="address" type="string" column="address" length="255" not-null="true"/>

<property name="username" type="string" column="username" length="16" not-null="true" unique="true" update="false">
</property>

<property name="password" type="string" column="password" length="12" not-null="true"/>

<property name="email" type="string" column="email" length="255" not-null="true"/>

</class>
</hibernate-mapping>



public void saveUser(User user) throws UserExistsException, DAOException
{
Session session = null;

Transaction tx = null;

try
{
session = sessionFactory.openSession();

tx = session.beginTransaction();

List results = (List) session.find("from com.playingwithmatches.xeg.webservices.User as user where user.username= ?",
user.getUsername(), Hibernate.STRING);

if(results.size() > 0)
{
throw new UserExistsException(user.getUsername(), "username already exists");
}

session.save(user);
session.flush();
tx.commit();
}
catch(HibernateException he)
{
logger.error("hibernate failed to save user " + he.getMessage());
throw new DAOException(he);
}

finally
{
try
{
session.close();
}
catch(Exception ex)
{
}
}
}



public void removeUser(String username) throws NoSuchUserException, DAOException
{
Session session = null;
Transaction tx = null;

try
{
session = sessionFactory.openSession();
tx = session.beginTransaction();

List results = (List) session.find("from com.playingwithmatches.xeg.webservices.User as user where user.username= ?",
username, Hibernate.STRING);

System.out.println("there is " + results.size() + " to delete");

if(results.size() < 1)
{
throw new NoSuchUserException(username, "specified user does not exist");
}

session.delete(results.get(0));
session.flush();

tx.commit();
}
catch(HibernateException he)
{
logger.error("hibernate failed to remove user " + he.getMessage());
throw new DAOException(he);
}

finally
{
try
{
session.close();
}
catch(Exception ex)
{
}
}
}

look to me it is a conceptual business problem.
If, in your business, you know many people are going to hit the same objects (and many will try to hit after deletion), it is a concurrency problem.
So you can keep going like this (optimistic lock), switch to optimistic lock with versionning or even use pessimisic lock (not recommanded).
Now if you know that in real life, it's not going to happen, then your test is not good, you have to rewrite it finding a way to tell that only one concurrent user hit each object at the same time.

Anthony,

Thanks for your reply. I think it is a concurrency problem.

It seems to be that optimistic locking helps in scenarios where i.e if two users retrieve and object and then store it, the later save attempt will throw an exception since it is stale data or ?

My problem is that although there are sequential removes and inserts, when they are concurrent things start clashing i.e so a legitimate remove user fails since a prior transaction completes after the checking of the object existing takes place.

Tom