我正在阅读SIP-14,它的概念Future非常有意义且易于理解.但有两个问题Promise:
SIP说Depending on the implementation, it may be the case that p.future == p.怎么会这样？是Future和Promise不是两种不同的类型？
我们Promise什么时候应该使用？示例producer and consumer代码:
import scala.concurrent.{ future, promise }
val p = promise[T]
val f = p.future
val producer = future {
val r = produceSomething()
p success r
continueDoingSomethingUnrelated()
}
val consumer = future {
startDoingSomething()
f onSuccess {
case r => doSomethingWithResult()
}
}
很容易阅读,但我们真的需要这样写吗？我试图只用Future和没有Promise来实现它:
val f = future …以下两个代码生成不同的结果:
def x = try{
true
} finally false
调用x得到 true
def y:Boolean = try{
return true
} finally {
return false
}
调用y得到 false
该return版本的行为与Java相同.
我个人从不在scala中使用'return'.但是知道scala如何评估try-catch-finally块的值是很好的.谢谢.
我正在构建一个传统的webapp,它通过JDBC进行数据库CRUD操作.我想知道在当前的请求处理线程中将jdbc操作放入actor是否合适.我做了一些搜索,但没有找到演示这个的教程或示例应用程序.
那么缺点和优点是什么？这个异步化是否会像nio一样提高appserver的容量(即处理的并发请求)？
这是我的标记:
<h:commandLink value="#{partial}" action="#{hello.setCurrentPartial(partial)}">
<f:ajax render="include" listener="#{hello.renderFragments}"/>
</h:commandLink>
我试图在Mojarra-2.2.8(wildfly 8.2.0.Final内置)和MyFaces-2.2.7(按照此处的指导安装)中运行此页面.令人惊讶的是,当点击链接时,mojarra hello.renderFragments首先调用,然后hello.setCurrentPartialMyFaces采用相反的顺序,即hello.setCurrentPartial首先调用.
所以我的问题是在JSF Spec中是否有动作调用顺序和ajax监听器的定义.如果定义了订单,哪个实现是正确的？
先前在scala-user邮件列表中询问了此问题,但没有确认答案.
scala> val T = new Pair(1, 2){
override def equals(obj:Any) = obj.isInstanceOf[(Int, Int)] && obj.asInstanceOf[(Int, Int)]._1 == this._1}
}
T: (Int, Int) = (1,2)
scala> T match {
case (1, 1) => println("matched")
case _ => println("not matched")
}
not matched
scala> (1, 1) match {
case T => println("matched")
case _ => println("not matched")
}
not matched
scala> T == (1, 1)
res15: Boolean = true
我认为常量(val)模式匹配结果取决于"等于"的返回值,但结果表明情况并非如此,那么标准是什么？
有人建议这case (1, 1) =>是一个提取器模式,Tuple2.unapply而是使用.所以我尝试了这些:
scala> Pair.unapply(T)
res1: …我刚刚使用Akka编写了一个JDBC连接池.
它使用一个actor来保存真实数据库连接的"maxPoolSize"集合.调用者向池actor询问连接并接收a Future[Connection]并且连接的状态变为"忙",直到调用者将其返回到池中connection.close.如果所有连接都忙,则新的传入连接请求将被置于等待队列(也由池actor保持).稍后当返回连接时,将满足等待请求.
这个逻辑的实现在akka中非常容易,只需要几十行代码.但是,当使用BoneCP 多线程测试来测试性能时(即调用者close在完成Future[Connection]返回时立即连接getConnection.基准测试traversed所有close请求和Await结果Future),我发现Akka版本比许多其他连接池实现慢例如tomcat-jdbc,BoneCP甚至是公共DBCP.
我试过调试的内容:
但没有看到明显的改善.
我的问题是:
在scala-arm项目中,我看到这样的代码:
def managed[A : Resource : Manifest](opener : => A) : ManagedResource[A] = new DefaultManagedResource(opener)
有人可以解释[A:资源:清单]的含义吗？
在apache HTTPComponent文档中有一个声明:
与流行的看法相反,NIO在原始数据吞吐量方面的性能明显低于阻止I/O的性能."
真的吗？有人可以更详细地解释一下吗？什么是典型的用例
请求/响应处理需要解耦
我想创建其类型由运行时数据确定的对象实例:
trait Business
case class Business1() extends Business
case class Business2() extends Business
object Business {
def fromData(data:Array[Byte]): Business = data(0) match {
case 1 => new Business1
case 2 => new Business2
case _ => throw new RuntimeException("data error")
}
}
上面的代码可以完成它的工作,但是它有一个关闭它的问题.每当我实现一个新的Business子类时,我都必须修改Business.fromData代码,例如
case 3 => new Business3
如何定义Business.fromData一次,以后可以添加Business3,Business4而无需注册？
编辑
我终于意识到这是一个完美的用例Multimethod,即基于某个参数的函数进行调度.所以更一般的问题应该是" 如何在scala中做多方法 "？我相信设计模式只是因为语言无能力而存在,这就是为什么我不愿意接受基于工厂的答案.
我知道sender在Future或调度程序中关闭方法调用或actor的内部状态是不安全的,但是actor的上下文呢？什么在ActorContext？在调度程序或将来的回调中关闭actor上下文是否安全？:
def receive: Receive = {
case Msg =>
system.scheduler.scheduleOnce(1 second) {
context.actorOf[ChildActor]
}
}