HibernateGtfsRelationalDaoImpl not commiting updates?

17 views
Skip to first unread message

Laurent Gregoire

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

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()
                .buildSessionFactory();
        HibernateGtfsFactory gtfsFactory = new HibernateGtfsFactory(
                sessionFactory);
        GtfsMutableRelationalDao store = gtfsFactory.getDao();

        store.open();
        Stop stop1 = new Stop();
        stop1.setName("OLD");
        stop1.setId(new AgencyAndId("X", "S1"));
        store.saveOrUpdateEntity(stop1);
        store.flush();
        store.close();

        store.open();
        Stop stop2 = store.getAllStops().iterator().next();
        stop2.setName("NEW");
        // store.updateEntity(stop2);
        System.out.println(store.getAllStops().iterator().next().getName());
        // --> NEW
        store.flush();
        store.close();

        System.out.println(store.getAllStops().iterator().next().getName());
        // --> OLD
    }
}
-------------------------- hibernate.cfg.xml ----------------------------------
<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE hibernate-configuration PUBLIC
        "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
        "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>
    <session-factory>
        <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" />
    </session-factory>
</hibernate-configuration>
--------------------------------------------------------------------------------------

Thanks for any hint!

--Laurent

Brian Ferris

unread,
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
(GtfsMapping.hibernate.xml).

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...

Brian

> --
> 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

unread,
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
Session.setDefaultReadOnly(true);
(http://docs.jboss.org/hibernate/core/3.5/reference/en/html/readonly.html#readonly-api-loaddefault)

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.

HTH,

--Laurent

Laurent Gregoire

unread,
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

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

Brian Ferris

unread,
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

unread,
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.

Brian


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

Laurent Gregoire

unread,
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
laurent....@gmail.com

Brian Ferris

unread,
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
Forward
0 new messages