You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by "Urbani, Edmund" <ed...@lilandit.com> on 2015/06/18 15:44:53 UTC
Dealing with transient and persistent objects in Wicket sessions
and models
Hello all,
this question is not directed solely at Wicket, but extends beyond that to web
app architecture and best practices.
I have been working mostly with the open-session-in-view pattern and Wicket's
loadable detachable models backed with Hibernate or similar ORM for my
applications.
This combination works fairly well until one starts to deal with transient
objects that may at some point become persistent, and have references to other
objects that already are persistent in the database. This object graph composed
of a mix of persistent and transient cannot safely be serialized, nor can
references to transient objects be removed at detach phase as they would then be
lost.
These situations usually arise in AJAX or Wizard-style scenarios. I have dealt
with them in various ways, but have not yet found a way that I am really
satisfied with:
1) always persist objects (undesirable in many cases as it might require you to
drop integrity constraints and do additional filtering when fetching objects
from the database to avoid "incomplete" instances or additional tables and
therefore overhead)
2) clear references to persistent objects and store that information elsewhere
(eg. in the model)
3) avoid setting references to the persistent instances in the transient one to
begin with (and again store IDs or models of selected persistent objects elsewhere)
4) deviate from open-session-in-view pattern on certain pages (may cause you to
run out of database connections or force you to deal with database timeouts etc.)
I don't think I am the only one running into these kinds of issues, so I'd like
to hear which patterns other developers apply or what they consider best practices.
Kind regards,
Edmund
--
Mit freundlichen Grüßen
Edmund Urbani
Liland IT Team
Email: Edmund.Urbani@Lilandit.com <ma...@lilandit.com>
Liland IT GmbH ...does IT better
Tel: +43 463 220111
Fax: +43 463 220111-33
Tel(GER): +49 221 65028588
Find us at Facebook http://facebook.com/Lilandit
http://green-badges.com
http://iventcloud.com
http://Lilandit.com
<http://www.LilandIT.com> <http://www.LilandIT.com>
Copyright © 2015, Liland IT GmbH
Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.
This email may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this email in error)
please notify the sender immediately and destroy this email. Any unauthorised
copying, disclosure or distribution of the material in this email is strictly
forbidden.
Re: Dealing with transient and persistent objects in Wicket sessions
and models
Posted by "Urbani, Edmund" <ed...@lilandit.com>.
On 06/21/2015 08:05 PM, Don Ferguson wrote:
> For persistence, I use the ActiveObjects ORM library, originally developed by Daniel Spiewak and now actively maintained by Atlassian. In AO, database entities are described by java interfaces. For your use case (transient objects that may or may not be persisted), I use a dynamic proxy whose implementation can be serialized. When setters are called on the entity, the proxy stores the (unsaved) data in a HashMap. An actual database record is only created on an explicit call to entity.save().
>
> By implementing it this way, panels that manipulate database records can operate on either new (transient) records or records that already exist. If the user cancels without saving, there is no detritus in the database to clean up.
>
> If anyone out there is interested in using AO with Wicket, I’d be happy to share my code & experience. I like the AO programming model, and its support for automatic schema migration means that you can change table definitions by adding/removing setters and getters in the entity interfaces; AO can infer the SQL to migrate tables to the new schema.
>
> For a quick (but somewhat outdated) introduction to AO, see: https://activeobjects.java.net/0.8.2/ActiveObjects.pdf <https://activeobjects.java.net/0.8.2/ActiveObjects.pdf>
> The repository can be found here: https://bitbucket.org/activeobjects <https://bitbucket.org/activeobjects>
>
> It’s an obscure framework, but I find it a pleasure to use, and it plays reasonably well with Wicket.
>
> -Don
>
Sounds interesting and I'll definitely be keeping an eye out for AO for future
projects. But for my current project I'll have to stick with Hibernate and by
hooking into the serialization process I have kind of made my own placeholder /
proxy. That approach seems to work fine so far.
Kind regards,
Edmund
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Dealing with transient and persistent objects in Wicket sessions and models
Posted by Don Ferguson <do...@gmail.com>.
For persistence, I use the ActiveObjects ORM library, originally developed by Daniel Spiewak and now actively maintained by Atlassian. In AO, database entities are described by java interfaces. For your use case (transient objects that may or may not be persisted), I use a dynamic proxy whose implementation can be serialized. When setters are called on the entity, the proxy stores the (unsaved) data in a HashMap. An actual database record is only created on an explicit call to entity.save().
By implementing it this way, panels that manipulate database records can operate on either new (transient) records or records that already exist. If the user cancels without saving, there is no detritus in the database to clean up.
If anyone out there is interested in using AO with Wicket, I’d be happy to share my code & experience. I like the AO programming model, and its support for automatic schema migration means that you can change table definitions by adding/removing setters and getters in the entity interfaces; AO can infer the SQL to migrate tables to the new schema.
For a quick (but somewhat outdated) introduction to AO, see: https://activeobjects.java.net/0.8.2/ActiveObjects.pdf <https://activeobjects.java.net/0.8.2/ActiveObjects.pdf>
The repository can be found here: https://bitbucket.org/activeobjects <https://bitbucket.org/activeobjects>
It’s an obscure framework, but I find it a pleasure to use, and it plays reasonably well with Wicket.
-Don
> On Jun 19, 2015, at 3:43 AM, Urbani, Edmund <ed...@lilandit.com> wrote:
>
> On 06/19/2015 01:59 AM, wix wrote:
>> Urbani, Edmund wrote
>>> I don't think I am the only one running into these kinds of issues, so I'd
>>> like
>>> to hear which patterns other developers apply or what they consider best
>>> practices.
>> Would like to hear the same. I've attempted to work through this in the
>> most Wicket-way I know how.
>>
>> The approach so far is a kind of LoadableDetachableModel that tries to be
>> smart about the persistent state of the underlying entity/object. A
>> persistence provider (entitymanager or such) would be injected into the
>> model or requested by the model, and a flag or flags used to track the state
>> of the underlying entity - is the entity currently managed? is the entity to
>> be retained (that is, not automatically detached)? is the entity currently
>> attached?
>>
>> So at the start of a wizard, the model is given a new entity and told that
>> it is un-managed and retained. As the model is passed to the next page or to
>> a previous page, the entity is serialized (not detached) and treated as
>> though it doesn't belong to a persistence context. At the end of the wizard
>> the model is told to persist the entity at which time it becomes managed but
>> not retained (so it detaches, and would be re-attached via persistence id
>> lookup when the model is next deserialized/loaded).
>>
>> A wizard or other set of pages working with an existing entity that was
>> selected from persistence just tells the model that it is managed and
>> retained. Then the model still doesn't "detach" in the sense of setting the
>> underlying entity to null, but it does "detach" from the JPA context and is
>> safely(?) serialized. Thereby changes made in wizard pages ride along to the
>> end as in the new entity case above, and aren't merged til whatever final
>> page/part logic says so. Cancelling out in the middle is simple since no
>> changed would have been persisted.
>>
>> It works for any generic entity in my projects so far, however my use case
>> right now isn't complicated by multi-entity editing; only one entity (one
>> model's underlying object) is being modified by a single form submission in
>> the open-session-in-view cycle.
>>
>> If there are other drawbacks to this approach or a better way (a more
>> Wicket-way)...
> Detaching from Hibernate / JPA session as you describe is another way to handle this. Makes me worry about concurrent modifications which might be committed in between detaching from / re-attaching to the persistence layer though.
>
> Also, I have considered separating the presentation layer (Wicket) from the managed database objects entirely and handle every interaction with the database through a service layer which maps database objects to/from a different set of classes tailored specifically for the UI and its various use cases. That would be the "cleanest" approach I can think of, and also the most expensive one to implement.
>
> However, currently I am trying to hook into the serialization process to untangle my partially persistent object graph as described in this article:
> http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html <http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html>
>
> This seems to be working so far (pending some thorough testing) even though it causes some weird exceptions in unit tests (javassist.CannotCompileException), which I have yet to fix.
>
> --
> Mit freundlichen Grüßen
> Edmund Urbani
> Liland IT Team
>
> Email: Edmund.Urbani@Lilandit.com <ma...@lilandit.com>
> Liland IT GmbH ...does IT better
> Tel: +43 463 220111
> Fax: +43 463 220111-33
> Tel(GER): +49 221 65028588
>
> Find us at Facebook http://facebook.com/Lilandit <http://facebook.com/Lilandit>
> http://green-badges.com <http://green-badges.com/>
> http://iventcloud.com <http://iventcloud.com/>
> http://Lilandit.com
>
> <http://www.lilandit.com/><Liland-130.png> <http://www.lilandit.com/>
> Copyright © 2015, Liland IT GmbH
>
> Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>
> This email may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this email in error) please notify the sender immediately and destroy this email. Any unauthorised copying, disclosure or distribution of the material in this email is strictly forbidden.
>
Re: Dealing with transient and persistent objects in Wicket sessions
and models
Posted by "Urbani, Edmund" <ed...@lilandit.com>.
On 06/19/2015 01:59 AM, wix wrote:
> Urbani, Edmund wrote
>> I don't think I am the only one running into these kinds of issues, so I'd
>> like
>> to hear which patterns other developers apply or what they consider best
>> practices.
> Would like to hear the same. I've attempted to work through this in the
> most Wicket-way I know how.
>
> The approach so far is a kind of LoadableDetachableModel that tries to be
> smart about the persistent state of the underlying entity/object. A
> persistence provider (entitymanager or such) would be injected into the
> model or requested by the model, and a flag or flags used to track the state
> of the underlying entity - is the entity currently managed? is the entity to
> be retained (that is, not automatically detached)? is the entity currently
> attached?
>
> So at the start of a wizard, the model is given a new entity and told that
> it is un-managed and retained. As the model is passed to the next page or to
> a previous page, the entity is serialized (not detached) and treated as
> though it doesn't belong to a persistence context. At the end of the wizard
> the model is told to persist the entity at which time it becomes managed but
> not retained (so it detaches, and would be re-attached via persistence id
> lookup when the model is next deserialized/loaded).
>
> A wizard or other set of pages working with an existing entity that was
> selected from persistence just tells the model that it is managed and
> retained. Then the model still doesn't "detach" in the sense of setting the
> underlying entity to null, but it does "detach" from the JPA context and is
> safely(?) serialized. Thereby changes made in wizard pages ride along to the
> end as in the new entity case above, and aren't merged til whatever final
> page/part logic says so. Cancelling out in the middle is simple since no
> changed would have been persisted.
>
> It works for any generic entity in my projects so far, however my use case
> right now isn't complicated by multi-entity editing; only one entity (one
> model's underlying object) is being modified by a single form submission in
> the open-session-in-view cycle.
>
> If there are other drawbacks to this approach or a better way (a more
> Wicket-way)...
Detaching from Hibernate / JPA session as you describe is another way to handle
this. Makes me worry about concurrent modifications which might be committed in
between detaching from / re-attaching to the persistence layer though.
Also, I have considered separating the presentation layer (Wicket) from the
managed database objects entirely and handle every interaction with the database
through a service layer which maps database objects to/from a different set of
classes tailored specifically for the UI and its various use cases. That would
be the "cleanest" approach I can think of, and also the most expensive one to
implement.
However, currently I am trying to hook into the serialization process to
untangle my partially persistent object graph as described in this article:
http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html
This seems to be working so far (pending some thorough testing) even though it
causes some weird exceptions in unit tests (javassist.CannotCompileException),
which I have yet to fix.
--
Mit freundlichen Grüßen
Edmund Urbani
Liland IT Team
Email: Edmund.Urbani@Lilandit.com <ma...@lilandit.com>
Liland IT GmbH ...does IT better
Tel: +43 463 220111
Fax: +43 463 220111-33
Tel(GER): +49 221 65028588
Find us at Facebook http://facebook.com/Lilandit
http://green-badges.com
http://iventcloud.com
http://Lilandit.com
<http://www.LilandIT.com> <http://www.LilandIT.com>
Copyright © 2015, Liland IT GmbH
Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.
This email may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this email in error)
please notify the sender immediately and destroy this email. Any unauthorised
copying, disclosure or distribution of the material in this email is strictly
forbidden.
Re: Dealing with transient and persistent objects in Wicket
sessions and models
Posted by wix <el...@style64.org>.
Urbani, Edmund wrote
> I don't think I am the only one running into these kinds of issues, so I'd
> like
> to hear which patterns other developers apply or what they consider best
> practices.
Would like to hear the same. I've attempted to work through this in the
most Wicket-way I know how.
The approach so far is a kind of LoadableDetachableModel that tries to be
smart about the persistent state of the underlying entity/object. A
persistence provider (entitymanager or such) would be injected into the
model or requested by the model, and a flag or flags used to track the state
of the underlying entity - is the entity currently managed? is the entity to
be retained (that is, not automatically detached)? is the entity currently
attached?
So at the start of a wizard, the model is given a new entity and told that
it is un-managed and retained. As the model is passed to the next page or to
a previous page, the entity is serialized (not detached) and treated as
though it doesn't belong to a persistence context. At the end of the wizard
the model is told to persist the entity at which time it becomes managed but
not retained (so it detaches, and would be re-attached via persistence id
lookup when the model is next deserialized/loaded).
A wizard or other set of pages working with an existing entity that was
selected from persistence just tells the model that it is managed and
retained. Then the model still doesn't "detach" in the sense of setting the
underlying entity to null, but it does "detach" from the JPA context and is
safely(?) serialized. Thereby changes made in wizard pages ride along to the
end as in the new entity case above, and aren't merged til whatever final
page/part logic says so. Cancelling out in the middle is simple since no
changed would have been persisted.
It works for any generic entity in my projects so far, however my use case
right now isn't complicated by multi-entity editing; only one entity (one
model's underlying object) is being modified by a single form submission in
the open-session-in-view cycle.
If there are other drawbacks to this approach or a better way (a more
Wicket-way)...
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Dealing-with-transient-and-persistent-objects-in-Wicket-sessions-and-models-tp4671222p4671240.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org