+30000000000000

So many pluses in fact, that we are already experimenting with this concept
at work.  Unfortunately, the source may not be "openable".  I'd be more than
willing to contribute to an open-source JTA monadic library.

for( tx <- context) {
   //Do stuff....
   if(somethingBad) tx.rollback()
   //Do more stuff
}

Just seems to fit the needs of my software *much* better than the magical
annotated method...errr... method seen in EJB and Spring.


-Josh

On Fri, May 29, 2009 at 9:16 PM, Jorge Ortiz <jorge.or...@gmail.com> wrote:

> I, too, would like to see Transactions be monadic.
>
> --j
>
>
> On Fri, May 29, 2009 at 3:54 PM, Meredith Gregory <
> lgreg.mered...@gmail.com> wrote:
>
>> Jonas,
>>
>> i applaud the effort. i agree with DPP sentiments regarding annotations.
>> That said, i feel pretty comfortable that transactions fit entirely in a
>> monadic context. Since LINQ demonstrates that query fits into monadic
>> context, and there's already at least one Scala implementation of 
>> LINQ<http://github.com/szeiger/scala-query/tree/master>,
>> might i suggest that you come up with a monadic presentation first and then
>> map the sugar to that. My guess is that the sugar will be informed by the
>> monadic presentation.
>>
>> To be suggestive... think of a context with a Tx object, TxCtxt, as like
>> an Option widget. Then you do stuff inside a transaction via
>>
>> for ( myTransactedWidget <- TxCtxt if <someCondition> ) yield {
>> <someOperationsThatNeedToBeTransacted> }
>>
>> If you implement flatMap, yada, on TxCtxt you can have fun with nested
>> transaction semantics. The point is that this should just work with a
>> LINQ-like presentation of query.
>>
>> Best wishes,
>>
>> --greg
>>
>>
>> On Fri, May 29, 2009 at 6:54 AM, Jonas Bonér <jbo...@gmail.com> wrote:
>>
>>>
>>> I'll go for closures. Much simpler and less intrusive into Lift.
>>> The current impl is based on Atomikos and Hibernate, I'll start with
>>> pushing that in and we can make it pluggable later.
>>> For example for Hibernate one need to add a line to the hibernate
>>> config to register the
>>> org.hibernate.transaction.TransactionManagerLookup class in order to
>>> make Hibernate aware of our TX manager.
>>>
>>> Should I fork the github repo and submit patches or how do you guys work?
>>>
>>> /Jonas
>>>
>>>
>>> 2009/5/29 Derek Chen-Becker <dchenbec...@gmail.com>:
>>> > I'd vote for closures. We use annotations for JPA because we have to,
>>> but
>>> > IMHO closures provide a nicer semantic approach because they
>>> syntactically
>>> > enclose the block where the action is occurring.
>>> >
>>> > Derek
>>> >
>>> > On Fri, May 29, 2009 at 7:44 AM, Jonas Bonér <jbo...@gmail.com> wrote:
>>> >>
>>> >> No perf difference. The annotations are turned into the same exact
>>> >> closures.
>>> >>
>>> >> 2009/5/29 Timothy Perrett <timo...@getintheloop.eu>:
>>> >> >
>>> >> >
>>> >> > Are there any performance implications considering closures vs
>>> >> > annotations?
>>> >> > Agreed that closures are more "lift like" however.
>>> >> >
>>> >> > Cheers, Tim
>>> >> >
>>> >> > On 29/05/2009 10:21, "marius d." <marius.dan...@gmail.com> wrote:
>>> >> >
>>> >> >>
>>> >> >> I think that would be really good. But I'd rather not use
>>> annotations.
>>> >> >> Personally I find closures approach a much better fit here.
>>> >> >>
>>> >> >> withTxRequired {
>>> >> >>   ... // do transational stuff
>>> >> >>
>>> >> >> }
>>> >> >>
>>> >> >>
>>> >> >> Br's,
>>> >> >> Marius
>>> >> >>
>>> >> >> On May 29, 11:55 am, Jonas Bonér <jbo...@gmail.com> wrote:
>>> >> >>> Hi guys.
>>> >> >>>
>>> >> >>> I have been talking with David Pollak the rest of the lift team
>>> about
>>> >> >>> adding JTA to Lift. I have implemented that for a product written
>>> in
>>> >> >>> Scala some time ago. Now some of that code is OSS
>>> >> >>> at:http://github.com/jboner/skalman/tree
>>> >> >>>
>>> >> >>> We used using two different APIs.
>>> >> >>> 1. Annotations (would require Lift to support proxied objects,
>>> e.g.
>>> >> >>> grab them from a factory):
>>> >> >>>
>>> >> >>> @TransactionAttribute(REQUIRED)
>>> >> >>> def transactionalMethod = { ... }
>>> >> >>>
>>> >> >>> 2. Call-by-name:
>>> >> >>>
>>> >> >>> withTxRequired {
>>> >> >>>   ... // do transational stuff
>>> >> >>>
>>> >> >>> }
>>> >> >>>
>>> >> >>> But I don't know what fits Lift and would like to know how you
>>> guys
>>> >> >>> would like to have JTA integrated.
>>> >> >>> At which level? Which APIs? Etc.
>>> >> >>>
>>> >> >>> --
>>> >> >>> Jonas Bonér
>>> >> >>>
>>> >> >>> twitter: @jboner
>>> >> >>> blog:    http://jonasboner.com
>>> >> >>> work:  http://crisp.se
>>> >> >>> work:  http://scalablesolutions.se
>>> >> >>> code:  http://github.com/jboner
>>> >> >> >
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Jonas Bonér
>>> >>
>>> >> twitter: @jboner
>>> >> blog:    http://jonasboner.com
>>> >> work:   http://crisp.se
>>> >> work:   http://scalablesolutions.se
>>> >> code:   http://github.com/jboner
>>> >>
>>> >>
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Jonas Bonér
>>>
>>> twitter: @jboner
>>> blog:    http://jonasboner.com
>>> work:   http://crisp.se
>>> work:   http://scalablesolutions.se
>>> code:   http://github.com/jboner
>>>
>>>
>>>
>>
>>
>> --
>> L.G. Meredith
>> Managing Partner
>> Biosimilarity LLC
>> 1219 NW 83rd St
>> Seattle, WA 98117
>>
>> +1 206.650.3740
>>
>> http://biosimilarity.blogspot.com
>>
>>
>>
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to