What does "persist" really mean ?

[Sébastien de Mapias]

Hi,
If I check Spring's doc of HibernateTemplate save(Object) method,
it says that it "persists the given transient instance". What does
this mean ??

Thanks.
SR

 

[Uwe Schmitt]

Hi,
If I check Spring's doc of HibernateTemplate save(Object) method,
it says that it "persists the given transient instance". What does
this mean ??

Thanks.
SR

persisting an object means converting its state to a representation
which will be saved to a db, filesystem, ...
later on you can load the representation and reconstruct the object
again.

the task of converting an objects state is called 'serialization'.
the representation can be in xml which is quite verbose, or in some
other ascii or binary format.

you can pass serialized objects through a network to some other
machine, where it is reconstructed again.
see http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp

greetings, uwe

 

[RedGrittyBrick]

Hi,
If I check Spring's doc of HibernateTemplate save(Object) method,
it says that it "persists the given transient instance". What does
this mean ??

I usually interpret that as to write to disk or some other non-volatile
medium which will retain the data if the Java program exits. Furthermore
to do so in such a way that the Java application can read the data when
it is restarted. I usually think in terms of persisting across a power
shut-down, though I suppose the term could be used in the context of
more volatile storage external to the application.

In the case of Spring/Hibernate I bet in 99% of cases it means it will
issue an SQL insert or update statement to a nearby DBMS.

I imagine "transient instances" are instances of Java classes (i.e.
objects) that are in peril if you pull the power cord out the back of
the computer.

Or have I misunderstood the question?

 

[Sébastien de Mapias]

In the case of Spring/Hibernate I bet in 99% of cases it means it will

issue an SQL insert or update statement to a nearby DBMS.

OK in this case 'save()' does not really "persist" the object *yet*,
until I commit, isn't it ? So the doc is rather unsufficient, am I
mistaken ? (I'm dealing with a database indeed)

To answer Eric Sosman: it's indeed the transitive usage of PERSIST
that made me misunderstand its meaning here (and there are many
other english words I'm not at ease with, because of their usage
in informatics -"leverage" is an example...-).

Thanks.
Seb

 

[Tom Anderson]

But probably less verbose than java.io.Serializable serialization.

Really? I'll run some tests ...

XML being "verbose" is one of those semi-true urban legends.

My take on it is that it is true until you compress your stream, at which
point it becomes very much not true.

"Verbose" compared to what?
ASN.1.

And at what benefit?

None.

tom

 

[Mike Schilling]

Really? I'll run some tests ...

Try comparing the Swing Archiver to serialization. Brcause the former
only stores properties that have non-default values, where
serialization stores every single non-transient field, it can result
in much smaller persistent formats.

 

[Lew]

Lew asked:

Lew:
Tom:
None.

XML has many benefits as an serialization format, not least that it is
semantically void. It is also human-readable. I am not familiar with
ASN.1, which may have similar advantages.

XML is also infinitely extensible and self-describing. The verbosity
buys something.

 

[Stefan Ram]

If I check Spring's doc of HibernateTemplate save(Object) method,
it says that it "persists the given transient instance". What does
this mean ??

It means to save.
¯¯¯¯
This might be an example, where the method name says more
than the documentation.

Which reminds me of a note, where someone recently wrote
»When I get a piece of code I need to understand, the first
thing I do is to strip all commments.«

 

[Roedy Green]

If I check Spring's doc of HibernateTemplate save(Object) method,
it says that it "persists the given transient instance". What does
this mean ??

see http://mindprod.com/jgloss/persistence.html

 

[Tom Anderson]

Lew asked:

XML has many benefits as an serialization format, not least that it is
semantically void.

"Semantically void"?

It is also human-readable. I am not familiar with ASN.1, which may have
similar advantages.

Well, it's certainly not human-readable [1]. Nor, sadly, is its
specification!

XML is also infinitely extensible and self-describing. The verbosity
buys something.

ASN.1 has the same degree of self-describingness as XML. The two are
really very similar when you get down to it. Indeed, there is a degree of
interoperability:

http://asn1.elibel.tm.fr/xml/

tom

[1] Kinda. ASN.1 is actually not an encoding, but a sort of framework for
encoding, within which there are a few specific encodings. The standard
one is the Basic Encoding Rules, BER, which is binary, fairly compact, and
self-describing. There's also the Packed Encoding Rules, PER, which is
maximally compact, but not self-describing. I think there are also
human-readable formats (there's certainly an XML one), but that's not
usually what people mean when they say ASN.1.

 

[Tom Anderson]

XML formats do not depend on nor impinge on the meaning of the content.
Put another way, XML (like ASN.1 from what you've told us) is
self-describing, so one need not refer to an external source to
interpret the contents.

Right, got it.

The meaning is entirely at the endpoints of an XML document's use, not
internal to the document. With other formats, for example positional
layouts where a field belongs to a certain position on a line, the
semantics are part of the format.

Yes. XML is more of a format architecture than a format per se, and it's
the formats you define with XML that impose meaning.

Although one could argue that XML does impose some meaning, in that it's
hierarchical: it doesn't have a natural way to describe directed acyclic
graphs, or matrices. The ID/IDREF mechanism does give you quite a good way
to do DAGs, but it's not quite as natural as the way XML deals with
hierarchies.

tom

 

[Arne Vajhøj]

OK in this case 'save()' does not really "persist" the object *yet*,
until I commit, isn't it ?

Now you really need a precise definition of persist.

Save will send the data to the database. And it may be seen
by other processes if the transaction isolation level is low.
But until commit is called then the data can still be told to
go away.

I will tend to agree with you: data is first persisted when they are
committed.

Arne