HibernateGtfsRelationalDaoImpl not commiting updates?

Skip to first unread message

Laurent Gregoire

Sep 22, 2011, 4:06:25 PM9/22/11
to onebusaway...@googlegroups.com

In the minimal test below, I can't figure out why my changes to the in-memory hsqldb does not get commited in memory. While in the transaction (between open() and close()) I see the changes made to the stop (first output is "NEW"), but after the call to close(), changes are gone (second output is "OLD"). Do I miss something obvious here? Uncommenting "store.updateEntity(stop2);" does not change anything.

-------------------------- HibernateDaoTest.java ----------------------------------
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import org.onebusaway.gtfs.model.AgencyAndId;
import org.onebusaway.gtfs.model.Stop;
import org.onebusaway.gtfs.services.GtfsMutableRelationalDao;
import org.onebusaway.gtfs.services.HibernateGtfsFactory;

public class HibernateDaoTest {

    public static void main(String[] args) throws Exception {
        SessionFactory sessionFactory = new Configuration().configure()
        HibernateGtfsFactory gtfsFactory = new HibernateGtfsFactory(
        GtfsMutableRelationalDao store = gtfsFactory.getDao();

        Stop stop1 = new Stop();
        stop1.setId(new AgencyAndId("X", "S1"));

        Stop stop2 = store.getAllStops().iterator().next();
        // store.updateEntity(stop2);
        // --> NEW

        // --> OLD
-------------------------- hibernate.cfg.xml ----------------------------------
<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE hibernate-configuration PUBLIC
        "-//Hibernate/Hibernate Configuration DTD 3.0//EN"

        <property name="connection.driver_class">org.hsqldb.jdbcDriver</property>
        <property name="connection.url">jdbc:hsqldb:mem:gtfs_store</property>
        <property name="connection.username">sa</property>
        <property name="connection.password"></property>
        <property name="connection.pool_size">1</property>
        <property name="dialect">org.hibernate.dialect.HSQLDialect</property>
        <property name="current_session_context_class">thread</property>
        <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>
        <property name="show_sql">true</property>
        <property name="hbm2ddl.auto">create</property>
        <mapping resource="org/onebusaway/gtfs/model/GtfsMapping.hibernate.xml" />
        <mapping resource="org/onebusaway/gtfs/impl/HibernateGtfsRelationalDaoImpl.hibernate.xml" />

Thanks for any hint!


Brian Ferris

Sep 22, 2011, 5:01:09 PM9/22/11
to onebusaway...@googlegroups.com
True enough. The reason this doesn't work is because all the GTFS
classes are marked "immutable" in the hibernate mapping

Historically, that was because we primarily used the
onebusaway-gtfs-hibernate to load GTFS data into a database, where it
would never be modified again. By marking the entity as "immutable",
it sped up data loading dramatically, as Hibernate could skip a lot of
checks on object querying and what not.

I'm not opposed to changing the mapping. I'm wondering if there is a
way to easily specify that all the classes are immutable
programatically for people who want to quickly load data read-only
into the database...


> --
> You received this message because you are subscribed to the Google Groups
> "onebusaway-developers" group.
> To post to this group, send email to onebusaway...@googlegroups.com.
> To unsubscribe from this group, send email to
> onebusaway-devel...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/onebusaway-developers?hl=en.

Laurent Gregoire

Sep 23, 2011, 3:45:50 AM9/23/11
to onebusaway...@googlegroups.com
Thanks for your reply, it make sense now. I effectively did not
checked hibernate mapping configuration.

Indeed there seems to be a way of making entities read-only by
default, programmatically, by calling

What could be done is to remove the immutable flag on mapping and
setting by default read-only when creating the DAO. Default behavior
would not change and it would allow one to reset this flag if needed.
If you are OK with that, I can give it a try and propose a patch.



Laurent Gregoire

Sep 23, 2011, 5:17:02 AM9/23/11
to onebusaway...@googlegroups.com
I'm currently trying to get numbers for the performance hit on using
mutable and non mutable mappings. I'm running a simple test loading a
decent GTFS file onto various databases (file-hsbdb, in-memory-hdqldb,
and postgres), and I don't see any significant performance hit without
immutable class, all my test run within the same few percent delta. Do
you have a scenario which can show a significant performance gain?

Laurent Gregoire

Sep 23, 2011, 5:18:20 AM9/23/11
to onebusaway...@googlegroups.com
Please read "file-hsqldb, in-memory-hsqldb, and postgres"...

Brian Ferris

Sep 23, 2011, 6:07:55 AM9/23/11
to onebusaway...@googlegroups.com
If I recall, it was more an issue when those entities were
subsequently queried from the system.

Brian Ferris

Sep 24, 2011, 3:28:20 PM9/24/11
to onebusaway...@googlegroups.com
After digging a little bit, I haven't been able to reproduce the
performance hit either. I've just committed an update that removes
the immutability.


On Fri, Sep 23, 2011 at 11:17 AM, Laurent Gregoire
<laurent....@gmail.com> wrote:

Laurent Gregoire

Sep 25, 2011, 6:59:24 AM9/25/11
to onebusaway...@googlegroups.com

Excellent. In the meantime, before a new official release, one can use the library with the mutable version of the mapping file copied from the library, as I am doing.

Laurent Grégoire

Brian Ferris

Sep 25, 2011, 7:11:46 AM9/25/11
to onebusaway...@googlegroups.com
You can also always just pull the latest SNAPSHOT build from the
OneBusAway repository.

On Sun, Sep 25, 2011 at 12:59 PM, Laurent Gregoire

Reply all
Reply to author
0 new messages