From: | Stefan Keller <sfkeller(at)gmail(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | Radosław Smogura <rsmogura(at)softperience(dot)eu>, pgsql-general List <pgsql-general(at)postgresql(dot)org>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues |
Date: | 2012-01-09 11:06:24 |
Message-ID: | CAFcOn29ewLB6JNa_Tp6GtBzzDZbZ2=FLWuB-0rHrS828XXmMOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-jdbc |
2012/1/9 Oliver Jowett <oliver(at)opencloud(dot)com>:
> Otherwise, what should JDBC do differently here? Be specific. It would
First, I pretty sure that Hibernate nor the Tomcat/Java GC are
misconfigured - since it works now after having installed the trigger
by hand.
To become more specific read the first two sections as a first hint
here in this official doc:
http://www.postgresql.org/docs/current/interactive/lo.html
I try to trace the JDBC calls coming from Hibernate (although the
problem seems to me pretty clearly located).
That investigation will take some time.
Yours, Stefan
2012/1/9 Oliver Jowett <oliver(at)opencloud(dot)com>:
> On 9 January 2012 14:29, Stefan Keller <sfkeller(at)gmail(dot)com> wrote:
>> 2012/1/9 Oliver Jowett <oliver(at)opencloud(dot)com>:
>>> As a LO is independent storage that might have multiple references to> it (the OID might be stored in many places), without explicit deletion> you need a GC mechanism to collect unreferenced LOs eventually -> that's what vacuumlo etc are doing.
>> I can follow that. But that's not what the JDBC user expects nor is it
>> explained (nor mentioned) in the JDBC docs.
>>
>> From a conceptual view I have just an entity MyWebcam with an
>> attribute called image. Attribute image is of attribute cardinality
>> 1:1 (and private):
>>
>> // Java using Hibernate/JPA:
>> @Entity
>> @Lob
>> @Basic(fetch=FetchType.LAZY)
>> public class MyWebcam {
>> private byte[] image;
>> private String name;
>> public byte[] getImage() { return image; }
>> public void setImage(byte[] _image) { image=_image; }
>> // ... other stuff
>> }
>>
>> That's the classic use case.
>> Isn't it obvious that if setImage() sets another byte[] that the image
>> space get's cleared by the layers below?
>> And since Hibernate chose to use one variant of JDBC, it's also JDBC
>> which has to take care about orphans.
>
> Well, either the Hibernate mapping is misconfigured, or your database
> is misconfigured i.e. you are not collecting garbage LOs. If you have
> a suitable GC mechanism configured, then what happens?
>
> Otherwise, what should JDBC do differently here? Be specific. It would
> be helpful if you could provide a native JDBC example, rather than a
> Hibernate example, since it's not clear what JDBC calls are being made
> by Hibernate.
>
> Oliver
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2012-01-09 11:07:30 | Re: Supporting SQL/MED DATALINK |
Previous Message | 邓尧 | 2012-01-09 09:49:25 | Re: Duplicated entries are not ignored even if a "do instead nothing" rule is added. |
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2012-01-09 11:29:03 | Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues |
Previous Message | Oliver Jowett | 2012-01-09 01:32:39 | Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues |