[Dbix-class] Clone DBIx::Class::Row object to new connection

[Gerhard Heift]

On Wed, Jun 02, 2010 at 08:47:15AM -0400, Rob Kinyon wrote:
> On Wed, Jun 2, 2010 at 08:01, Gerhard Heift
> <ml-dbix-class-20090107-b968 at gheift.de> wrote:
> >> As for concurrent transactions ... that's what forking is for.
> >
> > Currently I write a GUI based on DBIx::Class in only one process (no threads,
> > no forks). I have windows to edit rows in the database. I use rowbased locking
> > and for this I like to have separate connections for each window. For this I
> > think I need the database cloning.
> 
> You do understand that since all of your connections are going to be
> in one process, you still don't have concurrent processing. Just
> because different window objects have different connections, they're
> still going to be processed one at a time. The only ways to get
> concurrency are forking or threading. As threading generally sucks (in
> general for many reasons and specifically in Perl), best to use
> forking.

I just use the concurrent connection for locking. If I start editing a row in
one window, and another one in another window b, I start a transaction and lock
the row till it is saved and commited. If one of the updates fails, the other
one is not influenced by the rollback:

1: open window A with row A in connection A
2: open window B with row B in connection B
3: start edit A:
  3.1: start transaction in A
  3.2: lock row A
4: start edit B:
  4.1: start transaction in B
  4.2: lock row B
5: make modifications in A, which will fail
6: make modifications in B, which will commit
7: save row A to database, database will rollback
8: save row B to database
9: commit B

If I would not use two database connections in this case, the connection used
for both rows would be rolled back and my locks would be gone. I would have to
refetch the data from the database and let the user resolve any conflict
between his modification and some which could be made by other connections on
the row after the rollback due to the missing lock.

> This is very much a design smell. I would urge you to rethink. If not,
> then I would reconnect in each window object and re-find the specific
> row. Don't do any fancy cloning.

This is the solution I used in the second post.

Regards,
  Gerhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100602/3809d102/attachment.pgp