# persistence layer

**URL:** <https://discourse.openehr.org/t/persistence-layer/14526>\
**Category:** Technical (archive)\
**Created:** [3 March 2006 13:04 UTC](https://discourse.openehr.org/t/persistence-layer/14526 "2006-03-03T13:04:54Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [17 March 2006 15:47 UTC](https://discourse.openehr.org/t/persistence-layer/14526/21 "2006-03-17T15:47:39Z")

</div>

There is some basic architecture overview information in section 6 of [http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf](http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf)

Otherwise the persistence notes I just uploaded may help the discussion.

- thomas

Bert Verhees wrote:

---

<div class="post-metadata">

**Author:** ![James\_Heywood](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/j/9fc348/32.png) [@James\_Heywood](https://discourse.openehr.org/u/James_Heywood)\
**Post date:** [17 March 2006 16:18 UTC](https://discourse.openehr.org/t/persistence-layer/14526/22 "2006-03-17T16:18:22Z")

</div>

Dear Group,

That only works if you know your username and password. I do not have those and did not sign up for the mailing. Emails to the webmaster have not produced any reply.  
&nbsp;&nbsp;  
Help!

-Jamie

James Allen Heywood  
d'Arbeloff Founding Director  
ALS Therapy Development Foundation  
215 First Street Cambridge MA 02142  
617 441 7222 - www.als.net - jheywood@als.net

---

<div class="post-metadata">

**Author:** ![Conrado\_Vina](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/c/ed8c4c/32.png) [@Conrado\_Vina](https://discourse.openehr.org/u/Conrado_Vina)\
**Post date:** [17 March 2006 16:30 UTC](https://discourse.openehr.org/t/persistence-layer/14526/23 "2006-03-17T16:30:35Z")

</div>

Hi,  
I am on the exact same situation.

Thanks in advance,  
Conrado

James Heywood, el 17/03/2006 01:18 p.m. dijo:

---

<div class="post-metadata">

**Author:** ![mikael](https://discourse.openehr.org/user_avatar/discourse.openehr.org/mikael/32/881_2.png) [@mikael](https://discourse.openehr.org/u/mikael)\
**Post date:** [17 March 2006 16:45 UTC](https://discourse.openehr.org/t/persistence-layer/14526/24 "2006-03-17T16:45:27Z")

</div>

Hi all,

Rong Chen wrote:

> Mikael Nyström wrote:
> 
> > Rong Chen wrote:
> > 
> > > Do you have any specific need for queries? If you don't need to query  
> > > the internals of the objects (or tree of them), it will be quite  
> > > simple to just serialize the whole object.
> > 
> > I agree with Rong that in simple cases is it enough with serialized

objects.

> > (But I must say that the alternative with applications like "real time  
> > data driven decision support systems" is much more scientifically  
> > interesting and fun. Otherwise we probably not use the full potential  
> > of openEHR.)  
> > &nbsp;&nbsp;  
> > This could be achieved by querying in-memory objects, why it has to be

done

> in the persistence layer? Maybe you can give some example, Mikael.

A data driven real time system (in this example a decision support system)  
relies heavily on fast and full access to the data. The systems often works  
with rules like “if parameter A and parameter B is \< C then check if  
parameter D1, D2, D3, D4, D5 and D6 is \> 10 and in that case trigger rules  
R1, R2, R3, R4, R5, R6 and R7”.

Of cause it is possible to implement data driven systems completely in Java  
and only relies on a database management system to store serialized data  
objects in BLOBs. For every parameter the system needs to check the system  
then needs to take the path to the object which contain the parameter the  
system needs, ask the database management system to retrieve the serialized  
Java object from its BLOB-storage in the database, deserialize the object to  
a readable form, store the object it in the computer memory, read the  
parameter you need from the object, invalidate your newly created object and  
not get back the memory used for the object until the garbage collector run  
it’s next turn. But this strategy needs large resources to run.

If the parameters are stored in direct readable form in the database  
management system it is possible for the application to just ask for the  
single data it needs and haven’t the need to spend time on deserializing of  
BLOBs into readable objects, store large object instead of just the needed  
parameter in the computer’s memory and the need for large object to be  
garbage collected.

An even more efficient alternative is to implement the rules directly in the  
database management system as triggers. Then the rules are applied by the  
database management system in the same native way as the data are handled in  
the database management system. But this alternative is only possible when  
the database management system is able to read the single data values and  
not, as in the serialized objects alternative, know that the single data  
values are inside a BLOB.

If we are talking about small data driven systems can I accept the “pure  
Java guy’s alternative” and do most of the processing in Java. But if we  
would like to have large data driven systems this alternative is needs in  
most cases to large resources to work, and we then need to use the “database  
engineer’s alternatives” instead.

> A generic, full-featured query service is tricky enough to do, so why  
> not separate the persistence concern from query related logic.

I can accept that it is trickier to implement a good persistence layer  
without any serialized objects, but it is definitely not rocket science to  
do it. So why not try, so we are able to use the data in more effective  
ways?

> Well, I would prefer to see a generic, all-purpose persistence layer,

defined

> by clear interface. Of course, the characteristics will be different  
> depending which implementation is actually used. Applications should be  
> probably built on top of EHR services, which are also generic,

all-purposed.

> So I wouldn't agree that the persistence layer should be very much defined  
> by any particular application. These two, application and persistence,  
> should be rather decoupled, and the services layer will be in between.

I agree that we need one well defined independent and good persistence layer  
interface. We therefore need to design the persistence layer interface for  
the most demanding applications.

&nbsp;&nbsp;Greetings,  
&nbsp;&nbsp;Mikael

---

<div class="post-metadata">

**Author:** ![Karsten\_Hilbert](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/k/e56c9b/32.png) [@Karsten\_Hilbert](https://discourse.openehr.org/u/Karsten_Hilbert)\
**Post date:** [17 March 2006 22:44 UTC](https://discourse.openehr.org/t/persistence-layer/14526/25 "2006-03-17T22:44:15Z")

</div>

Well, even in a GP EMR system we want decision support. I  
don't think there's any such thing as a "small" system in  
your sense. It's rather a question of what the system is  
going to be used for no matter large or small.

Karsten

---

<div class="post-metadata">

**Author:** ![mikael](https://discourse.openehr.org/user_avatar/discourse.openehr.org/mikael/32/881_2.png) [@mikael](https://discourse.openehr.org/u/mikael)\
**Post date:** [17 March 2006 23:00 UTC](https://discourse.openehr.org/t/persistence-layer/14526/26 "2006-03-17T23:00:41Z")

</div>

Hi all,

Karsten Hilbert wrote:

> Mikael Nyström wrote:
> 
> > If we are talking about small data driven systems can I accept the “pure  
> > Java guy’s alternative” and do most of the processing in Java. But if we  
> > would like to have large data driven systems this alternative is needs in  
> > most cases to large resources to work, and we then need to use the  
> > “database engineer’s alternatives” instead.
> 
> Well, even in a GP EMR system we want decision support. I  
> don't think there's any such thing as a "small" system in  
> your sense. It's rather a question of what the system is  
> going to be used for no matter large or small.

I used "small" and "large" in a broad sense. If anyone feel more comfortable  
to read "small" as "low usage" and "large" as "high usage" or "not  
intensive" and "intensive" or "few users" and "many users" or similar things  
is it ok for me. 🙂 I just need to be able compare two alternatives with  
different demands.

&nbsp;&nbsp;Greetings,  
&nbsp;&nbsp;Mikael Nyström

---

<div class="post-metadata">

**Author:** ![David\_Forslund](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/d/71c47a/32.png) [@David\_Forslund](https://discourse.openehr.org/u/David_Forslund)\
**Post date:** [18 March 2006 00:18 UTC](https://discourse.openehr.org/t/persistence-layer/14526/27 "2006-03-18T00:18:53Z")

</div>

This good reference, and there are now numerous persistence enabling systems built around it. One which we have found to work very well  
and quite efficiently is ObjectRelationalBridge (OJB) from Apache. We use a rather generic persistence interface in OpenEMed and map it  
to a number of persistence mechanisms. This enables us to leverage the performance of different systems for different applications. The most efficient usually is an object database.

Dave Forslund  
Bert Verhees wrote:

[Previous page](https://discourse.openehr.org/t/persistence-layer/14526.md?page=1)