Paul Sturrock wrote:Its usually the responsibility of the driver to support SSL if the database supports it, so you shouldn't have to do any socket programming yourself. The driver will also hide the mechanics of the connection from you (well, it is an deliberate layer of abstraction after all ) so you can't get at it via normal JDBC code. I don't know if there are drivers that supprt SSL for MySQL, but the driver it does supply is open source so you could possible extend it to do the SSL stuff?
Paul Sturrock wrote:
I've actually followed some advice and took most of the transactions out.
Transactions for reads are unnecessary. Transactions for data manipulation are mandatory. The only (sort of) exception to this is unless you are running in auto commit mode, which be default you are not. Using auto commit you are using transaction implicitly.
Generation (of any kind) in Hibernate only happens when you perform an insert or update. If you are not running in a transaction, the generation stuff will never commit.
Paul Sturrock wrote:
Well to be fair to Hibernate, the only annotations or mappings that are ignored are those that could contradict or undermine the fetch strategy defined in your HQL. Either the annotations had to be ignored or part of the HQL had to be ignored, you can't have both honoured. I'll not defend how well documented this is however.
In your previous post you had wrapped your read in a transaction. Are you flushing the session etc. in that same transaction?
Paul Sturrock wrote:Ah. When you said your were using fetch stuff, I assuming you were using it in your HQL. One annoying feature of Hibernate is if you use an HQL query the majority of your fetching annotations/mappings will be ignored. Try using a Criteria query or the "eager fetch join" stuff in your HQL.
Paul Sturrock wrote:OK. Well what should be happening is behind the scenes Hibernate will "Hydrate" the object, where by your mapped type will be populated based on the results on whatever JDBC result set you are using. Given your initial HQL query:
will translate into a SQL query like:
you can be sure (give or take the implementation specifics of whatever database/driver you are using) the state of your ResultSet should not need Hibernate to go back to the database. My guess is the extra selects you are seeing are the result of your association mapping. Can you post your annotated POJOs?
Also, there will be an overhead because you wrap everything in a transaction. I'd ditch that part an only use transactions when updating the data.
Paul Sturrock wrote:I'm not sure I follow your design. Are you intending to update every Sensor and Transmitter object whenever your user uses your application?
From the JavaDocs forSession.refresh() say:
It is inadvisable to use this to implement long-running sessions that span many business tasks. This method is, however, useful in certain special circumstances. For example
* where a database trigger alters the object state upon insert or update
* after executing direct SQL (eg. a mass update) in the same session
* after inserting a Blob or Clob
Are you doing any of the above? You say your application is single user, so I'm guessing no?