Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues

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.

Yours, Stefan

2012/1/9 Oliver Jowett <oliver(at)opencloud(dot)com>:
> On 9 January 2012 12:40, Stefan Keller <sfkeller(at)gmail(dot)com> wrote:
>
>> There's an important principle that the code which "allocates"
>> resources is also responsible to release it.
>
> That's one resource allocation model, yes. The other common model is
> that resources are freed when there are no remaining references to
> them, i.e. a GC model.
>
>> AFAIK in this case it's JDBC which choses to use LO (which creates
>> pg_largeobjects entries) and it's therefore also JDBC which has to
>> clean up.
>
> If the application calls LargeObjectManager.create() then it's also
> responsible for eventually calling LargeObjectManager.unlink().
>
> If you're using JDBC's Blob API, there's no API there to tell the
> driver to actually delete the underlying data (there is Blob.free(),
> but that appears to just be about freeing local resources, not the
> underlying storage).
> 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.
>
> What do you suggest that the driver does differently here? (Perhaps we
> could do something like interpret Blob.truncate(0) as "delete the blob
> right now" - but is that what Hibernate actually does?)
>
> (Much of this is the whole LO vs. bytea argument all over again. If
> you want to store data with a lifetime that's the same as the row it's
> embedded in, then bytea is a much better mapping)
>
> Oliver