So your situation is that you are updating non-detached entities and usually
(but possibly not always) want optimistic locking. This can be handled on a
case-by-case basis without altering Hibernate's internals. Look for
"bulkEditPersonsByDTOs" in:
http://jumpstart.doublenegative.com.au
Just for the interested:
After some more research I found that setting the version manually (which is
not recommended by Hibernate) didn't work because of what is described here:
https://forum.hibernate.org/viewtopic.php?p=2293177&sid=2969aa867c7086b4a3c7a68bda853690#p2293177
It's a really old p
Thanks for the example (and JumpStart in general).
You point on doing the commit in onValidate makes sense, so i changed that.
I removed the manual version check as you suggest (which ofcourse makes
sense). So I actually ended up having what I had at the start of making this
mail thread. So I e
The following is a working example. It uses hidden version. Try opening in two
browsers and changing the person in both - you'll get the optimistic lock
exception. Don't check the versions yourself - leave that to Hibernate.
http://jumpstart.doublenegative.com.au/jumpstart/examples/inpu
Thanks for the ideas, I will look into this :)
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-Hibernate-optimistic-locking-tp5718413p5718431.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
Doesn't seem to work.
It does work if I do the following:
.tml
-
.class
--
@Property
private Integer version;
void setupRender() {
version = person.getVersion()
}
void onSuccess() {
if(version == person.getVersion) {
// do update
} else {
// don't do
If you ready to go deeper, you can change a bit of tapestry-hibernate source
code to implement it (NOT TESTED)
1. Add a version field (annotated with @Version) to your entity.
2. Add a field version to PersistedEntity.
3. In EntityPersistentFieldStrategy, store version along with id and
entity-t
Nice idea and seems to work.
I changed to Integer version, because as you all said it is recommended and
timestamp is sligthly less safe.
So I have this now:
Index.class
public class Index {
@Inject
private PersonRepository personRepo;
@Property
private
On Fri, 30 Nov 2012 10:08:54 -0200, nquirynen
wrote:
Hi,
Hi!
Thanks for the explanation. Yes with "I understand its not working" I
meant my approach is failing. I understand optimistic locking is
working, but just don't know how to make use of it.
So you mean I have to use Persist ins
I don't think @Persist will work.
If you ready to go deeper, you can change a bit of tapestry-hibernate source
code to implement it (NOT TESTED)
1. Add a version field (annotated with @Version) to your entity.
2. Add a field version to PersistedEntity.
3. In EntityPersistentFieldStrategy, store
Hi,
Thanks for the explanation. Yes with "I understand its not working" I meant
my approach is failing. I understand optimistic locking is working, but just
don't know how to make use of it.
So you mean I have to use Persist instead of activation context?
--
View this message in context:
http
Should have been
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-Hibernate-optimistic-locking-tp5718413p5718416.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsub
In order to use optimistic locking, hibernate recommends that you use an
integer version annotated with @Version on your entity.
@Entity
public class Person implements Serializable {
@Column
private String name;
@Version
@Column
private Integer version;
// getters and set
On Fri, 30 Nov 2012 08:47:55 -0200, nquirynen
wrote:
Hi,
Hi!
When I submit the form it will always first get the Person object again
through onActivate so I understand why this isnt working.
It's actually working. Optimistic locking doesn't seem to actually be what
you think it is. Hi
14 matches
Mail list logo
